分布式微服务架构概述初探
本文作者：IMWeb Jianglinyuan 原文出处：IMWeb社区 未经同意，禁止转载
微服务架构简介
微服务架构（MSA）的起源应该要追溯到国外著名架构师Martinfowler于2014年编写的一篇博文中，其中阐述了微服务架构的整体设想。他用这样一句话概述了对微服务架构的评价："今天在软件架构方面，除了微服务这个名称没有什么新的了"。
微服务架构是一种服务化架构风格，通过将功能分散到各个离散的服务中以实现对解决方案的解耦。随着业务系统的需求不断的扩大，SOA架构下的ESB变得越来越来庞大，而且大型互联网公司对开发、测试、部署的流程的效率的追求不断提高，微服务架构也就应运而生了。为了让系统能够尽可能快的相应各种需求和外界因素的变化，需要软件开发的系统流程和实践层面上提出可行的方案，分布式微服务架构就是在这个基础上，于软件技术和架构层面衍生而来的应对之道。
微服务架构诞生的必然性
为了最大限度复用已有资产，保护IT资产的投资，大多数异构系统并没有使用统一服务化框架进行深入改造。通过将业务接口发布成标准的Web服务（例如SOAP），利用XML序列化格式进行数据交换。部分遗留系统由于技术等原因无法改造，直接通过企业服务总线（ESB）进行异构协议的转换、Data Mapper和消息路由，实现与其他服务的互通。不同组件服务化使用的技术和划分原则不同，SOA服务化之后的质量也良莠不齐，部分设计不合理的服务并没有体现服务化之后的价值。
SOA架构解决了应用服务化的问题，随着服务化实践的不断深入，服务规模越来越庞大，服务治理面临的挑战也越来越多，微服务架构风格应运而生。实际上它的诞生并非偶然：敏捷开发强调迭代开发，快速交付可用的功能；持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力；CI自动化构建帮助我们简化环境的创建、编译、打包和部署；DevOps的流行促进小团队独立运作和交付。受这些因素的综合影响，以及SOA服务化实施多年的经验累积，综合因素共同作用促使为服务架构诞生。
分布式微服务的整体架构分析
当今很多的国际大型互联网公司已经开始采取这种微服务的模式来构建自己的系统，如亚马逊、eBay和Netfix等，国内著名互联网公司阿里巴巴内部某些业务也开始尝试使用这种模式进行系统的架构。微服务最核心的思想就是将业务系统拆分成一组较小的、低耦合、互联的服务。
每个服务通常拥有不同的特征或功能，例如订单管理、客户管理等。每个微服务可以抽象成具有其特征的六边形架构的小型应用，该六边形架构包括业务逻辑以及各种与之相适配的适配器。一些微服务会暴露其API给其他的微服务或者应用程序消费，还有一些微服务可能是提给UI层使用的。每个微服务实例通常是运行在VM或者Docker容器上。
应用程序的每个功能区域都由自己的微服务实现。此外，Web应用程序被分成一组更简单的Web应用程序（例如用于乘客管理的服务或者用于管理司机的服务）。这使得部署变得更加简单。
每个后端服务公开一个REST API，或者是特定语言的SDK，其他服务可以通过这种方式消费另一个微服务。例如，司机管理的微服务可以使用通知系统的微服务来获取当前司机身边潜在的乘客。UI微服务可以调用其他的微服务来做数据的处理和组装，以便给前端开发者提供更合理的数据，这也很符合现在比较流行的前后端分离的开发模式，后端工程师更注重在微服务性能的开发，而前端工程师则更关注在应用的业务逻辑开发上。服务同样还可以使用基于异步的消息通信系统。服务间的通信将再后面的章节中做出详细的介绍。
在这种模式下，微服务的REST API会提供给PC端或者其他终端设备消费。但是应用程序不能直接访问后端的服务。这个过程中，通信需要被一个API网关作为中介参与调解。API网关负责的任务主要是负载均衡、缓存、访问控制、API流量的控制和监控，可以使用NGINX来实现。
同时，微服务架构模式也会明显的影响应用程序和数据之间的关系。和传统的每个应用都共享单个数据库模式相反，微服务架构中的每个微服务都拥有自己的数据库。这种做法确保它可以保持松耦合。
综上所示，分布式微服务的架构图我们可以初步的总结为下图所示。
我们再次回顾上一章节中的类Uber应用的架构设计，我们根据微服务架构的原理，可以将类Uber应用拆分成不同的微服务模块，如乘客管理（Passenger）、司机管理（Driver）、系统通知（Notification）、相关支付（Payments）等等微服务。每对需要连通的微服务之间通过REST API互联互通，通过API网关对每个微服务的接口进行管理。
在微服务架构的模式下，我们会将每个服务可以通过Docker或者VM部署在云服务器上.
在运行的时候，Trip Management微服务由多个服务实例组成。每个微服务的实例都是一个Docker容器。为了实现高可用性，容器可以在多个VM上运行。在微服务的实例前面都搭载了负载均衡，例如NGINX。通过NGINX分配实例的请求。同时，负载均衡器还可以处理其他的问题，如缓存、访问控制、API流量监控。 初步的建构搭起来之后，我们就应该思考更细致的问题了。微服务与微服务之间如何感知？微服务又该怎么样管理呢？这就是服务发现的问题了。 这个时候我们就需要一台类似于服务注册中心的服务，传统的服务发现问题的解决方案有两种：客户端服务发现（client-side discovery）和服务端服务发现（server-side discovery）。这两种方案都可以用来管理服务与服务之间的关系。
- 服务端服务发现
服务端服务发现是指当客户端向负载均衡器发送一个请求的时候，负载均衡器不会直接去调用相关的微服务，而是会去一个服务注册表中查询相关服务实例的地址，然后路由到相关路由上。这种模式下，服务实例会在服务注册表上进行管理。服务端服务发现的相关逻辑可以用如下图表示。
- 客户端服务发现
客户端服务发现是指把服务发现的工作放到客户端来做。客户端负责管理可用的微服务实例，以及对其进行负载均衡。客户端向服务注册表发送请求，然后由客户端使用一个负载均衡的算法去决定选择当前被调用服务的具体哪一个实例。客户端发现的相关逻辑可以用下图表示。
综上所述，我们可以从数据、部署、通信、服务发现等问题的角度上对微服务做出一个架构性的总结。如图3-5所示。 同时我们可以对微服务架构主要特征做出如下：
(1) 原子服务，专注于做一件事情：与面向对象原则的"单一职责原则"类似，功能越单一，对其他功能的依赖就越少，内聚性就越强，以达到高内聚、松耦合。
(2) 高密度部署：重要的服务可以独立进程部署，非核心服务可以独立打包，合并到同一个进程中，服务被高密度部署。物理机部署，可以在同一台服务器上部署多个服务实例进程；如果是云部署，则可以利用LXC（例如Docker）实现容器级部署，以降低部署成本，提升资源利用率。
(3) 敏捷交付：服务由小图团队负责设计、开发、测试、部署、线上治理、灰度发布和下线，运维整个生命周期支撑，实现真正的DevOps。
(4) 微自治：服务足够小，功能单一，可以独立打包、部署、升级、回滚和弹性伸缩，不依赖于其他服务，实现局部自治。
分布式微服务架构与SOA的差异
两者主要的差异如下：
- 服务拆分粒度
SOA首先要解决的是异构应用的服务化；微服务强调的是服务拆分尽可能小，最好是独立的原子服务。
- 服务依赖
传统的SOA服务，由于需要重用已有的资产，存在大量的服务间依赖；微服务的设计理念是自治、功能单一独立，避免依赖其他服务产生耦合，耦合会带来更高的复杂度。
- 服务规模
传统SOA服务粒度比较大，多数会采用将多个服务合并打包成War包的方案，因此服务实例数比较有限；微服务强调尽可能的拆分，同时有很多服务会独立部署，这将导致服务鬼母急剧膨胀，对服务治理和运维带来新挑战。
- 结构差异
微服务化之后，服务数据的激增会引起架构质量属性的变化，例如企业集成总线ESB逐渐被P2P的虚拟总线替代；为了保证高性能、低时延，需要高性能的分布式服务架构保证微服务架构的实施。
- 服务治理
传统基于SOA Governance的静态治理转型为服务运行动态微治理、实时生效。
- 敏捷交付
服务由小团队负责微服务设计、研发、测试、部署、线上治理、灰度发布和下线，运维整个生命周期支撑，实现真正的DevOps。
微服务架构的优点
微服务架构模式有很多的好处。首先，它解决了应用系统复杂性的问题。它将一个单体架构的系统分解成一组服务。虽然业务系统的总量不变，但是应用程序已经分解成一个个可以被管理的模块或者服务。每个服务具有以RPC或者消息驱动的API形式，以及拥有明确的边界。微服务的开发速度更快、更容易理解和维护。
第二，这种架构使得每个服务都能够由专注该服务的团队独立开发。开发人员可以自由选择任何的有优势的技术，只要符合规定的API协议。当然，大多数公司都希望能避免无政府状态并限制技术的选型。然而，这种自由意味着开发人员不需要使用已经过时的技术。当编写新服务时，他们可以选择使用当前的技术或者选择新的更有优势的技术。比如在处理一个高I/O的微服务的时候，可以选择近几年才兴起的Node.JS语言。
第三，微服务架构模式使得每个微服务能够独立部署。开发人员不再对以往的部署和测试所带来的恐惧感到害怕。在这种架构下，每个需求都可以在微服务开发完之后测试立即部署。微服务架构使得连续部署成为可能。
最后，微服务架构模式使每个服务能够被独立扩展。同时，你可以根据你的硬件资源，进行更合理的部署。例如，你可以在EC2高计算的实例上部署CPU密集型图像处理服务，而在EC2高内存I/O的实例上部署内存数据库服务。