微服务是什么？

一、微服务的由来？

The term "microservice" was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on "microservices" as the most appropriate name. James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices - Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA" was pioneering the style at web scale as were many of the others mentioned in this article - Joe Walnes, Daniel Terhorst-North, Evan Botcher and Graham Tackley.

翻译：

2011年5月在威尼斯附近的软件架构师研讨会上讨论了“微服务”一词，以描述与会人员认为这是他们中许多人最近探索的一种通用架构风格。2012年5月，同一小组决定将“微服务”作为最合适的名称。James于2012年3月在克拉科夫的微服务-Java和Unix方式中以33rd学位的案例研究提出了其中一些想法 ，与Fred George差不多在同一时间。Netflix的Adrian Cockcroft将这种方法描述为“细粒度的SOA”，正如本文中提到的许多其他人（乔·沃恩斯，丹尼尔·特霍斯特·诺斯，埃文·博特彻和格雷厄姆·塔克利）一样，在网络规模上引领了这种风格。

二、什么是微服务？

 查了很多资料，目前对于微服务并没有明确的定义，但是这并不影响我们去了解它。

简单来说，微服务架构风格是一种将单个应用程序开发为一组小服务的方法，每个小服务都运行在自己的进程中，服务间通信采用轻量级通信机制（通常是restful api）这些服务围绕业务功能构建，并且可以通过全自动部署机制独立部署。这些服务基于一个集中化的管理，不同服务可以用不同的编程语言编写，并使用不同的数据存储技术。

我们用一张图来对比一下单体应用程序与微服务架构程序的区别

        单体应用是成功的，但是随着业务的扩展，特别是随着越来越多的应用程序被部署到云端。变更变的复杂，对应用程序的一小部分更改，需要重新构建和部署整个整体。随着时间的推移，保持一个好的模块化结构通常是很困难的，这使得保持只影响该模块中的一个模块的更改变得更加困难。

       所以，该来的还是来了，现实的需求催生了微服务的出现。

三、微服务体系结构的特点

        微服务没有明确的定义，但是微服务具备一些共同的特征：

1、通过服务实现组件化

     这里我们定义组件是一个软件单元，可以独立地替换和升级。 通过服务（而不是类似三方库）的方式实现组件化，就是因为服务是可独立部署的，这很重要。

     三方库（libraries）：可以链接到程序中，并使用内存函数调用调用的组件

     服务（services）：服务是进程外组件，它通过web服务请求或远程过程调用（rpc）等机制通信

2、围绕“业务”组织开发团队

     当希望将大型应用程序拆分为多个部分时，管理层通常将重点放在技术层，从而导致组建了UI团队，服务器端逻辑团队和数据库团队。当团队按这些方向分开时，即使是简单的更改也可能导致跨团队项目，需要时间和预算批准。聪明的团队会围绕此问题进行优化，组建跨职能团队。

    Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

                                                                                                                                                                                                                -- Melvin Conway, 1968

   译：任何设计系统（定义广泛）的组织都将产生一个其结构是该组织的通信结构的副本的设计。

                                                                                                                                                                                                                -- 梅尔文·康威

   大白话就是你想要的什么样的系统，就要有对应结构的团队。 一定程度上来说，一个合理的团队会决定产品的质量甚至产品的生命。

      

3、是产品而不是项目

      我们看到的大多数应用程序开发工作都使用项目模型：目的是交付某些软件，然后将其视为已完成。完成后，将软件移交给维护组织，并解散构建该软件的项目团队。

微服务的支持者倾向于避免这种模式，认为团队应该负责产品的整个生命周期。

4、智能端点和傻瓜式管道（Smart endpoints and dumb pipes）

     当在不同的进程间构建通讯结构时，我们看到了许多产品和方法，它们强调在通信机制本身中加入重要的智能功能。 企业服务总线（EBS）就是一个例子，其中EBS总线一般包括用于消息路由、编排、转换和应用业务规则的复杂工具。

     微服务社区支持另一种方法：智能端点和傻瓜式管道。从微服务构建的应用程序的目标是尽可能地“高内聚，低耦合”——它们拥有自己的域逻辑，在经典的Unix意义上更像过滤器——接收请求，适当地应用逻辑并生成响应。这些都是使用简单的REST风格协议来编排的，而不是像WS-Choreography或BPEL这样的复杂协议、或者通过一个中心工具编排。

     最常用的两种协议是HTTP请求-响应 和 轻量级消息传递，对前一种协议，一个很好的表述是：

     Be of the web, not behind the web（成为Web， 而不是隐藏在Web后面）

                                  -- Ian Robinson

      第二种常用方法是通过轻量级消息总线来进行消息传递。像傻瓜一样，除了提供可靠的异步结构其他事情什么都不做， "智能功能" 在于生产和消费消息的各个端点（指各个微服务）中。

      在一个整体中，组件在进程中执行，它们之间的通信方式通过方法调用或者函数调用。而将一个整体变为微服务，最大的问题在于改变沟通模式。  这两种方式对大部分的web来说都是足够的，但是极端性能追求的话，会用到RPC等方式。

5、分散治理

     集中治理的后果之一是在单一技术平台上进行标准化，经验表明，这种做法会带来局限性。     

     将单体应用拆分成多个服务，那么我们的每个服务就有选择不同的技术栈的机会。想用node.js建立一个简单的报告页面？ok。 想用C++做一个接近实时的组件？没问题。 你想换一种更适合一个组件的读取行为的不同风格的数据库？我们可以重建它。

     当然，不能因为可以做，而必须这么做。 但是以微服务的方式划分系统意味着你可以进行选择。

6、分散数据管理（去中心化数据管理）

     看个图

        微服务更倾向于让每个服务管理自己的数据库，或者同一数据库技术的不同实例，或完全不同的数据库系统 - 这就是所谓的混合持久化(Polyglot Persistence)。你可以在单体应用程序中使用混合持久化，但它更常出现在微服务里。 

       对跨微服务的数据来说，需要使用事务来保持一致性，而众所周知，分布式事务时出名的难以实现。 因此微服务强调服务间的无事务协调，即数据一致性要求达到最终一致性，并且一致性问题能够通过补偿操作来解决。

既然CAP无法同时满足，P又是必须的，那么对CA的取舍就是必然的。

7、基础设施自动化

     有必要开发持续交付工具来解决集成、测试、部署的问题。

8、容错设计

    使用服务作为组件的一个结果是，需要对应用程序进行设计，以便它们可以容忍服务故障。 任何服务调用都可能因为被调用服务不可用而失败，客户端必须尽可能优雅的应对这种失败。

    由于服务随时可能发生故障，因此快速检测到故障，并在可能的情况下自动恢复服务，是十分重要的。 微服务应用程序应当非常重视服务的实时监控，检查架构元素（数据库每秒收到多少请求）和业务相关指标（例如每分钟收到多少订单）。语义监视可以为发生错误的情况提供预警，触发开发团队进行跟进和调查。

   这对于微服务架构特别重要，因为微服务偏好编排和事件协作（可以说负载均衡），这会带来突发行为。 虽然很多专家称赞偶发事件的价值，但事实的真相是，突发行为有时 可能是一件坏事情。监控对于快速发现不良突发行为是至关重要的，

四、微服务与SOA

      当我们谈起微服务时，一个常见的问题就会出现：是否微服务只是十多年前出现的“面向服务的架构（Service-Oriented Architecture）” ？这是有道理的，因为微服务风格与SOA拥护者所支持的非常相似。然而，问题是SOA意味着太多不同的东西，而且大多数时候我们遇到的称为SOA的东西与我们在这里描述的风格有很大的不同，这通常是由于他们专注ESB，来集成各个应用。

      尽管有人认为微服务是SOA的一种形式，但是我们会发现他们之间的含义是不同的。

参考资料：https://martinfowler.com/articles/microservices.html#Microservices