Microservice

1. 简介 微服务的实施，涉及的内容非常多，包括服务治理、配置中心、服务网关、服务熔断、分布式事务、集群、消息总线等等，各个部分开源的产品也非常多： 服务治理：阿里的Dubbo以及当当维护的DubboX、Netflix的Eureka、Apache的Consul等； 配置中心：Spring Cloud的Config、百度的Disconf、Netflix的Archaius、淘宝的Diamond等； 服务跟踪：Spring Cloud的Sleuth、Twitter的Zipkin等 服务网关：Netflix的Zuul等 …… 开源组件如此众多，在实施微服务时，势必带来技术选型方面的困扰，不仅要了解各个技术的作用、易用性、优缺点，还需要知道其他组件对其支持程度，以及组件之间的依赖、协作关系，因此，很多公司在一开始就心生畏惧甚至直接放弃。 为了解决上述问题，Spring Cloud应运而生。它不单独解决微服务某一方面的问题，而是提出了微服务一整套解决方案。Spring Cloud整合了很多开源的微服务产品，针对微服务某一方面的问题，它提供了默认的实现，从而极大的简化了微服务实施的技术难度，使得技术人员不必再关注技术选型方面的问题，大大节约了成本。 简言之，Spring Cloud是一套构建于Spring boot之上的微服务框架，它整合了大部分微服务实施所需的组件，并提供了默认实现，使得复杂的微服务实施变得简单化。官网地址： http://projects.spring.io/spring-cloud/ 2. 特点 Spring Cloud专注于为典型用例提供良好的开箱即用体验，并为其他用户提供可扩展性机制。 分布式/版本化配置 服务注册和发现 路由 服务间调用 负载均衡 断路器 分布式消息 3. 组件 Spring Cloud整合了微服务架构所需的大部分开源组件，包括： Spring Cloud Config 即配置管理工具，由git(也支持svn、本地文件系统等)存储库支持的集中式外部配置管理，实现了配置的外部化存储。 Spring Cloud Netflix 核心组件，整合了Netflix OSS开源的组件，包括许多子组件： Eureka：服务治理组件，包括服务注册、发现，对Netflix的Eureka进行整合； Hystrix：容错管理组件，断路器，对Netflix的Hystrix进行了整合； Ribbon：客户端负载均衡，也是Netflix的开源组件，Spring Cloud进行了整合； Feign：基于Ribbon和Hystrix的声明式服务调用，整合Netflix的Feign； Zuul：网关组件，智能路由、访问过滤，整合Netflix的Zuul； Archaius：外部化配置组件，整合netflix的Archaius； Spring Cloud Bus 轻量级消息总线，用于集群间通信，传播集群间状态改变，例如动态更新配置。 Cloud Foundry 将您的应用程序与Pivotal Cloud Foundry集成。提供服务发现实现，还可以轻松实现受SSO和OAuth2保护的资源。 Spring Cloud Open Service Broker 提供构建实现Open Service Broker API的服务代理的起点。 Spring Cloud Cluster 基于Zookeeper，Redis，Hazelcast，Consul的选举和通用状态模式的抽象实现。 Spring Cloud Consul Hashicorp Consul的服务发现和配置管理。 Spring Cloud Security 为Zuul代理中的负载平衡OAuth2 rest客户端和身份验证头中继提供支持。 Spring Cloud Sleuth Spring Cloud应用程序的分布式跟踪，兼容Zipkin，HTrace和基于日志（例如ELK）的跟踪。 Spring Cloud Data Flow 组合微服务应用程序的本地云编排服务，提供了易用的DSL、拖放式GUI和REST-API共同简化了基于数据管道的微服务整体编排。 Spring Cloud Stream 轻量级事件驱动的微服务框架，可快速构建可连接到外部系统的应用程序。采用声明式模型，在Spring Boot应用程序之间使用Apache Kafka或RabbitMQ发送和接收消息。 Spring Cloud Stream App Starters 基于Spring Boot的Spring应用程序集成，可提供与外部系统的集成。 Spring Cloud Task 一种短命的微服务框架，用于快速构建执行有限数据处理的应用程序。用于向Spring Boot应用程序添加功能和非功能功能的简单声明。 Spring Cloud Task App Starters Spring Cloud Task App Starters是Spring Boot应用程序，可能是任何进程，包括不能永久运行的Spring Batch作业，它们在有限的数据处理期后结束/停止。 Spring Cloud Zookeeper 使用Apache Zookeeper进行服务发现和配置管理。 适用于Amazon Web Services的Spring Cloud 与托管的Amazon Web Services轻松集成。它提供了一种使用众所周知的Spring习语和API（如消息传递或缓存API）与AWS提供的服务进行交互的便捷方式。开发人员可以围绕托管服务构建应用程序，而无需关心基础结构或维护。 Spring Cloud Connectors 使各种平台中的PaaS应用程序可以轻松连接到数据库和消息代理（该项目以前称为“Spring Cloud”）等后端服务。 Spring Cloud CLI Spring Boot CLI插件，用于在Groovy中快速创建Spring Cloud组件应用程序 Spring Cloud Gateway 一款基于Project Reactor的智能可编程路由器。 Spring Cloud OpenFeign 通过自动配置和Spring环境以及其他Spring编程模型习惯用法提供Spring Boot应用程序的集成。 Spring Cloud Function 通过函数促进业务逻辑的实现。它支持无服务器提供商之间的统一编程模型，以及独立运行（本地或PaaS）的能力。 ...

可能出乎很多人意料之外的一个事实是，微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律。 1. 概述 微服务是最近非常火热的新概念，大家都在追，也都觉得很对，但是似乎没有很充足的理论基础说明这是正确的，给人的感觉是 不明觉厉 。前段时间看了Mike Amundsen《远距离条件下的康威定律----分布式世界中实现团队构建》（是Design RESTful API的作者）在InfoQ上的一个分享，觉得很有帮助，结合自己的一些思考，整理了该演讲的内容。 可能出乎很多人意料之外的一个事实是，微服务很多核心理念其实在半个世纪前的一篇文章中就被阐述过了，而且这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律(Conway’s Law). 在康威的这篇文章中，最有名的一句话就是： Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. — Melvin Conway(1967) 中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构**。看看下面的图片，再想想Apple的产品、微软的产品设计，就能形象生动的理解这句话。 用通俗的说法就是：组织形式等同系统设计。 这里的系统按原作者的意思并不局限于软件系统。据说这篇文章最初投的哈佛商业评论，结果程序员屌丝的文章不入商业人士的法眼，无情被拒，康威就投到了一个编程相关的杂志，所以被误解为是针对软件开发的。最初这篇文章显然不敢自称定律（law），只是描述了作者自己的发现和总结。后来，在Brooks Law著名的人月神话中，引用这个论点，并将其“吹捧”成了现在我们熟知“康威定律”。 2. 康威定律 Mike从他的角度归纳这篇论文中的其他一些核心观点，如下： 第一定律 Communication dictates design 组织沟通方式会通过系统设计表达出来 第二定律 There is never enough time to do something right, but there is always enough time to do it over 时间再多一件事情也不可能做的完美，但总有时间做完一件事情 第三定律 There is a homomorphism from the linear graph of a system to the linear graph of its design organization 线型系统和线型组织架构间有潜在的异质同态特性 ...

在过去几年中，“微服务架构”这一术语如雨后春笋般涌现出来，它描述了一种将软件应用程序设计为一组可独立部署的服务的特定方式。虽然这种架构风格没有明确的定义，但在组织、业务能力上有一些共同的特征：自动化部署，端点智能化，语言和数据的去中心化控制。 “微服务” - 软件架构拥挤大街上的有一个新术语。虽然我们自然的倾向是轻蔑的一瞥将它一带而过，然而我们发现这一术语描述了一种越来越吸引人的软件系统风格。我们已看到，在过去的几年中有许多项目使用了这种风格，并且到目前为止结果都还不错，以致于这已变成了我们同事在构建企业级应用程序时默认使用的架构风格。然而，遗憾的是并没有太多的信息来概述什么是微服务风格以及怎样用这种风格。 简单来说，微服务架构风格 [1] 是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。 与单体风格作对比有助于开始解释微服务风格：单体应用程序被构建为单一单元。企业级应用程序通常由三部分组成：客户端侧用户接口(由运行于开发机上的浏览器里的HTML页面和Javascript组成)，数据库(由插入到通用关系型数据库管理系统中的许多数据表格组成)，服务端应用程序。服务端应用程序处理HTTP请求，执行领域逻辑，从数据库中检索、更新数据，选择、填充将要发送到浏览器的HTTP视图。服务端应用程序是一个单一的逻辑可执行单体 [2] 。系统的任何改变都将牵涉到重新构建和部署服务端的一个新版本。 这样的单体服务器是构建这样一个系统最自然的方式。处理请求的所有逻辑都运行在一个单一进程中，允许你使用编程语言的基本特性将应用程序划分类、函数和命名空间。你认真的在开发机上运行测试应用程序，并使用部署管道来保证变更已被正确地测试并部署到生产环境中。该单体的水平扩展可以通过在负载均衡器后面运行多个实例来实现。 单体应用程序可以是成功的，但人们日益对他们感到挫败，尤其是随着更多的应用程序被部署在云上。变更周期被捆绑在一起 —— 即使只变更应用程序的一部分，也需要重新构建并部署整个单体。长此以往，通常将很难保持一个良好的模块架构，这使得很难变更只发生在需要变更的模块内。程序扩展要求进行整个应用程序的扩展而不是需要更多资源的应用程序部分的扩展。 Figure 1. 单体和微服务 这些挫败导向了微服务架构风格：构建应用程序为服务套件。除了服务是可独立部署、可独立扩展的之外，每个服务都提供一个固定的模块边界。甚至允许不同的服务用不同的的语言开发，由不同的团队管理。 我们不会声称微服务风格是新颖的、创新的，其本质至少可以回溯到Unix的设计哲学。但我们的确认为没有足够的人仔细考虑微服务架构，并且如果使用它很多软件实现将会更好。 1. 微服务架构的特征 我们无法给出微服务架构风格的一个正式定义，但我们可以尝试去描述我们看到的符合该架构的一些共性。就概述共性的任何定义来说，并非所有的微服务架构风格都有这些共性，但我们期望大多数微服务架构风格展现出大多数特性。虽然本文作者一直是这个相当松散的社区的活跃用户，我们的目的是试图描述我们工作中和我们知道的一些团队的相似努力中的所见所闻。特别是我们不会制定一些可遵守的定义。 1.1. 通过服务组件化 只要我们一直从事软件行业，一个愿望就是通过把组件插在一起构建系统，如同我们看到的现实世界中事物的构造方式一样。在最近的二十年中，我们看到作为大多数语言平台一部分的公共库的大量汇编工作取得了很大的进展。 当谈到组件时，我们遭遇困难的定义：组件是什么。我们的定义是：组件是一个可独立替换和独立升级的软件单元。 微服务架构将使用库，但组件化软件的主要方式是分解成服务。我们把库定义为链接到程序并使用内存函数调用来调用的组件，而服务是一种进程外的组件，它通过web服务请求或rpc(远程过程调用)机制通信(这和很多面向对象程序中的服务对象的概念是不同的 [3] 。) 使用服务作为组件而不是使用库的一个主要原因是服务是可独立部署的。如果你有一个应用程序 [4] 是由单一进程里的多个库组成，任何一个组件的更改都导致必须重新部署整个应用程序。但如果应用程序可分解成多个服务，那么单个服务的变更只需要重新部署该服务即可。当然这也不是绝对的，一些变更将会改变服务接口导致一些协作，但一个好的微服务架构的目的是通过内聚服务边界和按合约演进机制来最小化这些协作。 使用服务作为组件的另一个结果是一个更加明确的组件接口。大多数语言没有一个好的机制来定义一个明确的 发布接口。通常只有文档和规则来预防客户端打破组件的封装，这导致组件间过于紧耦合。服务通过明确的远程调用机制可以很容易的避免这些。 像这样使用服务确实有一些缺点，远程调用比进程内调用更昂贵，因此远程API被设计成粗粒度，这往往更不便于使用。如果你需要更改组件间的责任分配，当你跨进程边界时，这样的行为动作更难达成。 直观的估计，我们观察到服务与运行时进程一一映射，但这仅仅是直观的估计而已。一个服务可能由多进程组成，这些进程总是被一起开发和部署，比如只被这个服务使用的应用进程和数据库。 1.2. 围绕业务能力组织 当想要把大型应用程序拆分成部件时，通常管理层聚焦在技术层面，导致UI团队、服务侧逻辑团队、数据库团队的划分。当团队按这些技术线路划分时，即使是简单的更改也会导致跨团队的时间和预算审批。一个聪明的团队将围绕这些优化，两害取其轻 - 只把业务逻辑强制放在它们会访问的应用程序中。换句话说，逻辑无处不在。这是Conway法则 [5] 在起作用的一个例子。 任何设计系统(广泛定义的)的组织将产生一种设计，他的结构就是该组织的通信结构。 — Melvyn Conway 1967 Figure 2. Conway法则在起作用 微服务采用不同的分割方法，划分成围绕业务能力组织的服务。这些服务采取该业务领域软件的宽栈实现，包括用户接口、持久化存储和任何外部协作。因此，团队都是跨职能的，包括开发需要的全方位技能：用户体验、数据库、项目管理。 Figure 3. 团队边界增强的服务边界 www.comparethemarket.com是按这种方式组织的一个公司。跨职能团队负责创建和运营产品，产品被划分成若干个体服务，这些服务通过消息总线通信。 大型单体应用程序也总是可以围绕业务能力来模块化，虽然这不是常见的情况。当然，我们将敦促创建单体应用程序的大型团队将团队本身按业务线拆分。我们看到这种情况的主要问题是他们趋向于围绕太多的上下文进行组织。如果单体横跨了多个模块边界，对团队个体成员来说，很难把它们装进他们的短期记忆里。另外，我们看到模块化的路线需要大量的规则来强制实施。服务组件所要求的更加明确的分离，使得它更容易保持团队边界清晰。 侧边栏：微服务有多大？ 虽然，“微服务”已成为这种架构风格的代称，这个名字确实会导致不幸的聚焦于服务的大小，并为“微”由什么组成争论不休。在与微服务实践者的对话中，我们发现有各种大小的服务。最大的服务报道遵循亚马逊两匹萨团队(也就是，整个团队吃两个披萨就吃饱了)的理念，这意味着团队不超过12个人。在更小的规模大小上，我们看到这样的安排，6人团队将支持6个服务。 这导致这样一个问题，在服务每12个人和服务每1个人的大小范围内，是否有足够打的不同使他们不能被集中在同一微服务标签下。目前，我们认为最好把它们组合在一起。但随着深入探索这种风格，我们一定有可能改变我们的看法。 1.3. 是产品不是项目 我们看到大多数应用程序开发工作使用一个项目模式：目标是交付将要完成的一些软件。完成后的软件被交接给维护组织，然后它的构建团队就解散了。 微服务支持者倾向于避免这种模式，而是认为一个团队应该负责产品的整个生命周期。对此一个共同的启示是亚马逊的理念 “you build, you run it” ，开发团队负责软件的整个产品周期。这使开发者经常接触他们的软件在生产环境如何工作，并增加与他们的用户联系，因为他们必须承担至少部分的支持工作。 产品思想与业务能力紧紧联系在一起。要持续关注软件如何帮助用户提升业务能力，而不是把软件看成是将要完成的一组功能。 没有理由说为什么同样的方法不能用在单体应用程序上，但服务的粒度更小，使得它更容易在服务开发者和用户之间建立个人关系。 ...