微服务

1. 简介

微服务的概念最初由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。
微服务是一种基于软件的系统架构，支持将小型独立的，像一个微型应用程序一样，能够以自己的方式独立运行的进程组合成复杂的应用程序。
这些个体组件之间通过语言无关的应用程序编程接口（API）和简单协议，比如远程方法调用（RMI），Restful Web服务或者Push Messaging，互相通信。
每个组件都有自己的存储，内存或者CPU资源，这使得硬件的利用更为简单，特别是在基于云的平台即服务（PaaS）上，只需要预配并且跟踪即可。开发团队可以使用自己喜欢的标准或者技术栈，只要确保和其他组件的互通性，能够组成最终的应用程序即可。
微服务架构将应用分成很多小的独立的部署单元，使应用具有更强的健壮性、更好的伸缩性、更容易持续集成。此外还提供了实时生产部署的能力，减少了传统的停机部署。每次只需要部署修改过的组件就行了。

还有一点需要注意的是，由于微服务架构是分布式的，它和事件驱动架构一样需要考虑契约的创建、维护和管理，远程访问的身份认证和授权。
微服务相对单体式应用来说有明显的好处：
(1)解决了单体式应用的复杂性问题，单个微服务很容易开发、理解和维护。
(2)每个微服务都可以由独立的团队来开发，可以自由选择开发语言。
(3)每个微服务可以独立部署，系统可以快速演进。
(4)可以对每个微服务进行独立扩展，极大的提高系统伸缩性及资源利用率。
但在一个单体式应用拆分成数十个乃至上百个微服务，由于服务数量的增加，以及微服务支持多种编程语言的特性，对软件的构建，部署，测试，监控都带来了全新的挑战。

2. 模式描述

2.1 独立部署单元

每个组件部署为独立单元，通过持续集成使得部署更容易，使应用之间和应用内部的组件高度解耦，提高了可伸缩性。

2.2 服务组件service component

服务组件的粒度可以很小也可以很大，既可以是一个独立的模块，也可以是应用的一部分。服务组件可以是包含一个或多个模块来提供某个单一功能，也可以是大型应用的业务独立的部分。如何确定服务组件的粒度是个很重要的问题。

2.3 分布式架构

微服务架构是一个分布式的（distributed）。架构内的所有组件之间是完全解耦的，并且可以通过某种远程访问协议（JMS、AMQP、REST、SOAP、RMI等）来访问。分布式特性使得微服务架构具有优越的伸缩性和易于部署性。
独立应用程序通常组件之间高耦合，测试和部署很繁琐，促使了微服务架构的持续集成的发展，将应用程序划分为多个可部署单元，也就是服务组件，每个组件可以独立开发测试和部署。
面向服务架构很强大，提供了空前的抽象级别、异构连接、服务编排、可简单调整就能适应业务的能力，但是它很复杂，难以理解和实现。对于大多数应用来说是杀鸡用牛刀。微服务架构简化了服务的概念，消除编制需求，简化了服务组件的连接和访问。

3. 模式拓扑

常见的微服务架构实现方式有三种：基于REST API、基于REST应用、集中消息处理。

3.1 基于REST API的拓扑结构

基于REST API的结构一般用于使用某种API暴露出小的独立的服务的网站。该结构由很细粒度的服务组件组成，每个组件只包含一个或几个模块来实现某个业务功能，并与其它服务保持独立。这些细粒度的服务组件可使用基于REST的接口访问，通常部署为独立的的基于Web的API层。例如Google、Yahoo、Amazon提供的一些目标单一的RESTful服务

3.2 基于REST应用的拓扑结构

基于REST应用的结构与上面的结构的不同之处在于客户端的请求是通过传统的基于Web或富客户端应用来接收的，而不是通过API层。应用的UI层被部署为独立的Web应用，通过简单的基于REST的接口远程访问服务组件。该结构中的服务组件一般是粗粒度的，适用于不是很复杂的中型应用。

3.3 集中消息处理的拓扑结构

集中消息处理结构与基于REST应用的拓扑结构很相似，只是使用轻量级的集中消息代理组件代替REST进行远程访问。它可以称为小型SOA架构。该消息代理组件不做任何的编排、转换或复杂的路由，它只是向服务组件远程传递消息。该结构一般用于大型应用或UI层与服务组件之间的传输层需要复杂控制的应用。与基于REST应用的拓扑结构相比，它有高级队列机制、异步消息处理、监控、异常处理、更好的负载均衡和可伸缩性。该结构的瓶颈通常通过使用代理集群代替集中的消息代理来解决。

4. 避免依赖和编制

微服务架构的一个主要难点是服务组件的粒度。粒度太大时享受不到架构的易于扩展性、可伸缩性、易于测试性、低耦合的优势。粒度太小时又导致需要服务编排，使简单的微服务架构变成了重量级的SOA架构。

当需要在UI层或API层需要编排服务时说明服务组件粒度太小，当处理单个请求需要组件之间通信时要么粒度太大要么业务功能分离得不合理。

服务间通信会导致组件之间的耦合，可通过共享数据库解决。例如，处理订单的服务组件需要客户信息，它可以直接去数据库查询，而不是调用客户信息服务组件。

如果一个服务组件需要的功能在另一个组件中，有时可以将其复制到该服务组件中（从而违反DRY原则：Don’t Repeat Yourself）。这是在使用微服务架构时需要权衡的，重复冗余的功能来保持组件的独立。

在不考虑组件粒度时，如果还是无法避免服务编排，那也许微服务架构就不适合该业务场景，因为分布式的原因，服务组件之间事务很难管理，需要使用事务处理框架，这无疑增加了实现的复杂度

5. 模式分析

下表展示了分层架构模式的通用架构特性的评级和分析。
整体灵活性
评级：高
分析：整体灵活性是对环境变化快速响应的能力。服务组件是独立部署单元，改变通常隔离在组件内，可以快速实现和部署。

易于部署
评级：高
分析：服务组件是低耦合的独立部署单元，可实现热部署和持续集成。

可测试性
评级：高
分析：业务功能被分散在服务组件内，对服务组件进行测试是很方便的。而服务组件之间是低耦合的，很少有涉及几个服务组件同时改动而需要联合测试的情况。

性能
评级：低
分析：虽然根据这个架构实现的性能可能还不错，但它的分布式特性决定了它不是一个高性能的架构。

可伸缩性
评级：高
分析：应用被分成独立的服务组件，每个组件可以单独地扩展。

开发容易度
评级：高
分析：业务功能被分散在独立且唯一的服务组件中，由于其作用域很小，开发起来很容易。很少有一个组件会影响另一个组件的情况，减少了开发人员之间冲突的可能。

6. 容器技术

围绕着云托管环境的如此多的应用程序和服务部署活*动，微服务架构已经深度依赖于容器化技术的使用。容器将微服务进程和应用程序隔离到更小的实例里，这些实例仅仅使用虚拟化了的操作系统，而不是整个虚拟机以及VM所包含的整个抽象硬件资源。

容器的常见使用方式包括Docker，一种基于Linux的开源实现，很多软件公司，比如Canonical，Red Hat和Parallels都支持Docker。一些PaaS服务，包括Google App Engine，Red Hat Open Shift，和Vmware的Cloud Foundry使用了Linux Containers（LXC）技术。