背景
你正在开发一个服务端的企业应用程序。它必须支持不同的客户端，包括桌面浏览器，移动端浏览器和原生手机应用。它需要暴露一个API接口给第三方消费。它需要通过web service或者消息机制与其他应用程序集成。它接受请求（HTTP请求和消息）；执行业务逻辑；访问数据库；与其他系统交换数据；返回HTML/JSON/XML响应。这个应用中，不同的功能区域都对应着不同的逻辑组件。
问题
该应用的部署架构？
限制
一个团队的开发人员正在开发这个应用
新的团队成员应该迅速上手
该应用应该容易理解和修改
你想尝试持续部署
你必须在不同机器上运行该应用的拷贝，以满足可扩展性和可用性的需求
你想尝试新的技术（框架，编程语言等）
解决方案
定义一种架构，将应用程序组织为松散写作的服务。这个方法对应于Scale Cube的Y轴。每个服务都定义了一组狭隘的相关功能。例如，应用程序可以包含订单管理服务，客户管理服务等等。
服务之间使用同步协议，例如HTTP/REST或者异步协议，例如AMQP交互。服务之间可以独立的开发和部署。每个服务拥有它自己的数据库，与其他服务解耦。服务之间的数据一致是通过Saga pattern管理。
示例
虚拟的电商应用
设想一下，你正在构建一个商城应用程序，为客户生成订单，验证库存和可用积分，快递商品。这个应用程序由以下几个组件构成：商城前端UI，它包括了用户界面；后端服务，包括检查积分，管理库存和运送商品。该应用程序包含一组服务。
展示代码
请访问 example applications developed by Chris Richardson。这些示例在github.com上，展示了微服务架构的各个方面。
结果
优势
该解决方案有以下优势：
- 允许持续交付和部署大型，复杂的应用程序
- 更好的可测试性 - 服务测试更小，更快
- 更好的部署能力 - 服务可以独立的部署
- 允许你围绕多个自动化团队组织开发工作。允许你围绕多个部门组织开发工作。每个部门负责一个或多个单独的服务。每个部门都可以独立开发，部署和扩展他们的服务。
- 每个微服务相对较小
- 很容易让每个开发人员理解
- IDE启动更快，让开发人员更有效率
- 应用启动更快，这让开发人员更有效率，而且加快开发速度
- 提高了错误隔离。例如，如果一个服务出现内存泄漏，仅有这个服务会受到影响。其他服务将继续处理请求。作为比较，单体架构中一个组件出现异常，将拖垮整个系统。
- 消除对一个技术栈的长期依赖。当开发一个新服务时，你可以选择新技术栈。同样，当对现有服务做出重大修改时，也可以用一个新技术栈来重写它。
弊端
该解决方案有以下弊端：
- 开发人员必须处理额外带来的分布式系统的复杂性。
- 开发工具/IDE面向的是构建单体应用，不为开发分布式应用程序提供明确支持
- 测试变得更复杂
- 开发人员必须实现服务内部的通信机制
- 实现跨多个服务的用例而不使用分布式事务非常困难
- 实现跨多个服务的用例需要部门之间的紧密合作
- 部署复杂性。在生产环境中，存在部署和管理包含多个不同服务类型的系统的操作复杂性。
- 内存消耗增加。微服务架构将N个单体应用替换成了N×M个服务实例。如果每个服务都运行在它独有的JVM（或者类似的运行时），这对隔离实例很游泳，这样就存在M倍的开销。还有，如果每个服务运行在它
独有的虚拟机（或者EC2实例），比如Netflix那样，开销会更高。
问题
你必须解决很多问题。
什么时候该采用微服务架构？
采用这个方法的一个挑战是决定什么时候使用它。当开发一个应用的第一个版本，你通常不会遇到必须采用这个架构才能解决的难题。此外，采用精心设计的分布式架构会减慢开发速度。这对初创公司是个主要问题，因为他们最大的挑战通常是迅速解决业务模型和对应的应用程序。使用Y轴拆分，会使迅速迭代变得更困难。然而，一段时间后，当挑战变成如何扩展，并且你需要使用功能分解时，这些纠缠的依赖可能使你难以将单体应用分解成一组服务。
如何将应用分解成服务？
另外一个挑战是决定该如何将系统拆分到微服务。这更是一门艺术，但是有一些策略可以帮上忙：
- 按业务能力拆分，定义与业务能力相对应的服务。
- 按领域驱动设计的子域拆分.
- 按谓词和用例拆分，定义与特定行为对应的服务。例如，一个“Shipping Service”对应运送订单。
- 按名词和资源拆分，定义与一个指定类型的entities/resources的所有操作相对应的服务。例如，一个“Account Service”对应管理用户账号。
理想角度，每个服务应该只拥有一小部分能力。Bob Martin讨论了采用单一职责原理（SRP）来设计类。SRP将一个类的职责定义为改变的理由，并且一个类只能有一个理由发生改变。将SRP应用到服务设计很有意义。
另一个帮助服务设计的类比是Unix工具设计理念。Unix提供了众多的工具，比如grep，cat和find。每个工具只明确做一件事，通常非常好，而且可以通过一个shell脚本和其他工具合并，提供复杂的任务。
如何保持数据一致性？
为了确保松耦合，每个服务都有它肚子的数据库。由于2阶段提交/分布式事务在多数应用中并不是一个选择 ，在不同服务之间保持数据一致是个很大的挑战。应用程序必须改为采用Saga模式。服务在数据发生更改时发布事件。其他服务订阅事件并更新它们的数据。有很多种方式可以可靠的更新数据和发布事件，包括Event Sourcing和Transaction Log Tailing。
如何实现查询
另外一个挑战是查询多个服务拥有的数据
相关的模式
有很多和微服务相关的模式。单体架构是微服务之外的另一选择。其他模式解决了你将在微服务架构中遇到的问题。
- 分解模式：
- 每服务每数据库模式介绍了一个服务怎样拥有其独有的数据库以实现松散耦合
- 网关模式定义了客户端怎样访问微服务架构中的服务
- 消息模式和远程调用模式是服务间通信的两种不同方法
- 每主机单服务和每主机多服务模式是两种不同的部署策略
- 横切关注模式和外部化的配置
- 测试模式：服务组件测试和服务集成测试
- 断路器
- Access Token
- 可观测的模式：
- UI模式
已知案例
大多数大型网站，包括 Netflix，Amazon和eBay都从单体架构进化到了微服务架构。
Netflix，知名的视频流服务，承担了30%的互联网访问流量，采用了大规模的，面向服务的架构。他们每天处理来自800个不同设备类型，针对视频流API的上十亿次调用。每个API调用平均分散出对后台服务的六次调用。
Amazon.com最开始采用两层架构。为了扩展，他们迁移为存在几百个后端服务的面向服务架构。一部分应用程序调用这些服务，包括Amazon.com网站和web服务API。Amazon.com网站访问100-150个服务，获取数据构建网页。
拍卖网站ebay.com也从单体架构进化到了面向服务架构。应用层有很多独立的应用程序。每个应用程序实现了特定功能领域的业务逻辑，比如购买和销售。每个应用程序采用X-轴切割；一部分应用，比如搜索，采用Y-轴切割。Ebay.com针对数据库层提供了X-，Y-，Z-风格的合并。
还有许多其他公司使用微服务架构的案例
