引言
微服务架构模式作为单体应用和面向服务架构(SOA)的可行替代方案，已经迅速在业界占领了一席之地。由于微服务架构模式还在持续演进中，所以业界对于它是干什么的，以及如何实现它还有很多的疑惑。这部分内容将给你提供必要的关键概念和基础知识，以及微服务架构模式的利弊和它是否适合你的应用。
模式描述
不论你选择何种拓扑结构或者实现风格，都有几个通用的核心概念来应用到通用架构模式中。第一个核心概念是独立部署单元。如下图，微服务架构中的每个组件都是独立的单元，能够通过有效且流线型的交付管道来提高可伸缩性，高度的将应用和组件解耦。
可能理解微服务架构模式最重要的概念是服务组件的理解。大型应用通过良好定义的粒度来拆分成服务组件。
服务组件通常有一个或多个模块（例如：java类）可以提供单一目的方法（例如：提供一个具体城镇的天气）或者是一个大型应用的一部分（例如：股票交易或者保险理赔）。设计一个合理的服务组件粒度是微服务架构模式最大的挑战。在后面的服务组件编排部分将会对这个挑战进行更多的讨论。
服务架构中的另一个关键概念是分布式架构，这意味着所有的服务组件互相是解耦的，并且可以通过一些远程访问协议进行访问（例如：JMS,AMPQ,REST,SOAP,RMI等）。微服务架构的分布式特性使他可以更好可扩展性以及部署特性。
微服务架构是从其他通用架构模式遇到的一些问题演进而来，而不是被创造解决未来遇到的问题。微服务体系架构从两个主要的来源演进而来：使用分层架构的单体应用和通过面向服务的分布式架构。
微服务一个演进路线是单体应用。从单体应用到微服务架构主要通过持续交付来实现，从开发到生产环境的持续部署管道概念简化了应用程序的部署。单体应用与它的组件为紧耦合的单个发布单元，这使得单体应用庞大，修改，测试和发布都很困难。通常这些因素都会导致单体应用在每次部署更新时都会遇到更多问题。微服务架构模式通过将应用程序分解为多个独立部署的单元解决了这些问题，这些部署单元称为服务组件，这些服务组件之间独立开发，测试和发布。
微服务的另一个演进路线是SOA。SOA模式非常强大，且提供了前所未有的抽象，异构连接，服务编排，将业务功能与IT能力结合起来，但是它对于大部分应用是复杂，昂贵，普遍难以理解与实现。微服务架构通过服务组件概念解决了这些复杂性问题，消除服务编排的需求并简化了服务组件的连接与访问。
模式拓扑
有很多方式可以实现微服务架构模式，但是有三个的架构拓扑脱颖而出：
基于REST API拓扑
基于应用REST拓扑
集中消息拓扑
基于REST API拓扑主要用于网站通过某种形式的API对外暴露小且独立的服务。下图展示了这个拓扑。这个拓扑由细粒度的服务组件组成，每个服务组件包含一个或者多个模块，每个模块负责实现具体的业务逻辑，每个服务组件独立于其他服务组件。在这个拓扑中，通常使用基于REST接口的形式封装这些细粒度的服务，并且这些服务通过基于Web的API层独立发布。
基于应用的拓扑与基于REST API拓扑不同的是，客户端的请求通过传统的基于web或者胖客户端的业务应用接收而不是API层。如下图，应用程序的用户层通过独立的web应用进行发布，用户层服务与服务组件通过REST接口进行访问。基于应用的服务组件与及基于REST API服务组件的不同之处在于：基于应用的服务组件一般会更大（更粗粒度），代表着整个业务应用的一部分功能，而不是细粒度，单一的服务。基于应用的拓扑通常应用于中小业务应用，这些业务应用一般业务复杂性相对较低。
另一个拓扑模式是集中式消息拓扑。这个拓扑与基于应用的拓扑类似，但是通过轻量级消息代理进行远程访问，而不是使用REST。不要把这个拓扑结构当成SOA或者SOA-lite架构。在这个拓扑中的轻量级消息代理并不执行任何编排，转换，或者复杂的路由(请参考消息驱动架构-Mediator)；它只是在拓扑中承担轻量级服务访问的传输。
集中式的消息拓扑经常用于大型业务应用或者需要在用户层和服务组件之间需要复杂的业务控制传输层。
避免服务依赖和编排
微服务架构模式的一个主要挑战是确定服务组件的一个正确粒度。如果服务组件粒度太粗，你可能又回归到单体应用了（发布，扩展，测试与松耦合统统都丢了）。然而，如果服务组件过于细粒度，就会需要服务编排，那么这就会导致你的微服务变成重量级SOA。
如果你发现你需要在应用的用户层或者API层编排服务组件，那么你的微服务中的服务组件就是过于细分（粒度太细）。与之类似，如果你发现为了处理一个请求，你需要进行服务间通信，那么，你的服务组件划分的过于细粒度或者他们并没有根据业务功能进行正确拆分。
服务间通信，会导致服务与服务的依赖，但是可以通过共享数据库解决。例如，如果一个服务组件需要处理互联网订单，订单需要查询用户信息，这种业务可以通过访问共享数据库得到这些信息，而不是调用用户服务组件的功能获取。
共享数据库可以处理数据需求，但是共享功能如何做？如果一个服务组件需要的功能在另一个服务组件中或者其他通用服务组件中，有时可以复制共享功能在这个服务组件中（违反了DRY原则：don't repeat yourself）。但是在大部分实现了微服务架构模式的业务应用中，这个实践非常常用。权衡一些业务逻辑的冗余，使得服务组件之间能够相互独立，并能能够独立发布。一些工具类可能会分到这些重复代码目录中。
如果你发现，不管服务粒度细分的粗或者细，你依然无法避免服务组件的编排，那么微服务架构可能不适合你的业务应用。由于微服务架构模式的分布式特性，一个事务的跨服务调用是难以维护的。微服务架构可能需要一个分布式事务框架来回滚事务，但是这会增加微服务架构的复杂性。
架构思考
微服务架构解决了很多单体应用和SOA中的常见问题。由于主体服务组件被拆分成小且独立发布的单元，使用微服务架构模式的构建的应用，通常健壮的，很好的扩展性，可以很容易的支持持续交付。
微服务架构模式的另一个好处是，它提供了一个实时产品发布能力，因此能够有效的减少传统应用的月度或者周度产品发布。由于服务组件之间通常是独立修改的，那么只有这个服务组件需要发布。如果你只有一个服务组件的实例，那么你可以在发布期间在用户层检测服务组件是否正在热发布中，然后将用户重定向到错误页面或者等待页面。但是，你也可以在实时发布期间，启动多个服务组件实例，这样可以在服务发布期间能够持续提供服务（在基于分层架构模式的应用，有时这是非常困难的）。
最后一个需要考虑的是，由于微服务架构也是分布式架构，一些复杂的问题解决需要事件驱动架构模式，包括关系建立，维护，管理，远程系统可用性和远程访问认证与授权。
模式分析
敏捷性：高
由于独立部署单元的概念，所以服务组件之间修改是隔离的，因此服务组件能够更快且容易发布。服务与服务之间松耦合，所以能够更快的响应变化。
易于部署：高
一般服务组件部署都是独立的软件单元，因此拥有在任何时候能够进行热部署。同时部署风险也大大降低，部署失败可以更快的回滚到老版本。
可测试性：高
将一个大型应用拆分成独立的小应用，测试可以被界定，能够更有针对性的进行功能测试。对一个特定服务组件的测试更容易，且更容易实施。服务组件是松耦合的，这样在修改服务的时候就不会中断应用的其他服务组件。
性能：低
微服务的分布式特性就不是高性能的应用架构。
可扩展性：高
每个服务组件独立扩展。
易于开发：高
服务小且独立范围界定，使得开发更容易，减少团队之间的协作。
