标签：style blog http ar io color os 使用 sp
This a translation of an article ( http://microservices.io/patterns/microservices.html) originally written and copyrighted by Chris Richardson ( http://twitter.com/crichardson).
假设你在开发一个服务端应用。该应用必须支持各种各样的客户端，包括桌面浏览器、手机浏览器和本地手机应用。应用可能也需要公开部分API供第三方使用，还可能与其他应用通过web service或消息代理(message broker)相集成。应用执行业务逻辑来处理请求(HTTP请求或者消息)；访问数据库；与其他系统交换消息；并返回HTML/JSON/XML类型的响应。
应用或是多层架构或是六角架构，并且包含多种类型的组件：
表示组件(Presentation components) - 响应处理HTTP请求，并返回HTML或JSON/XML(对于web service API)
业务逻辑(Business logic) - 应用的业务逻辑
数据库访问逻辑(Database access logic) - 数据访问对象用于访问数据库
应用集成逻辑(Application integration logic) - 消息层，如基于Spring的集成
这些逻辑组件分别响应应用中不同的功能模块。
应用的部署架构是什么？
该应用由一个开发者团队在维护
团队新成员必须快速上手
应用应该易于理解和修改
你想对应用进行持续集成
你必须在多台机器上部署多份应用的拷贝，以满足可伸缩性和可用性的要求
你想使用新技术(框架、编程语言等)
通过采用伸缩立方(Scale Cube)(特别是y轴方向上的伸缩)来架构应用，将应用按功能分解为一组相互协作的服务的集合。每个服务实现一组有限并相关的功能。比如，一个应用可能包含订单管理服务，客户管理服务等。
服务间通过HTTP/REST等同步协议或AMQP等异步协议进行通讯。
服务独立开发和部署。
每个服务为了与其他服务解耦，都有自己的数据库。必要时，数据库间的一致性通过数据库复制机制或应用级事件来维护。
我们假设你在构建一个电子商务应用，应用从客户接收订单，验证库存和可用额度，并派送订单。应用包含多个组件，包括StoreFrontUI，用来实现用户接口，以及一些后台服务，用于检测信用额度、维护库存和派送订单。
应用作为一组服务部署。
这个方案有一些好处：
每个微服务都相对较小
易于开发者理解
IDE反应更快，开发者更高效
web容器启动更快，开发者更高效，并提升了部署速度
每个服务都可以独立部署 - 易于频繁部署新版本的服务
易于伸缩开发组织结构。你可以对多个团队的开发工作进行组织。每个(双披萨[1])团队负责单个服务。每个团队可以独立于其他团队开发、部署和伸缩服务。
提升故障隔离(fault isolation)。比如，如果一个服务存在内存泄露，那么只有该服务受影响，其他服务仍然可以处理请求。相比之下，一体架构的一个出错组件可以拖垮整个系统。
每个服务可以单独开发和部署
消除了任何对技术栈(technologh stack)的长期投入(long-term commitments)
这个方案也有一些缺点：
开发者要处理分布式系统的额外复杂度。
开发者工具/IDE是面向构建一体应用的，并没有显示提供对开发分布式应用的支持
测试更加困难
开发者需要实现服务间通信机制
不使用分布式事务实现跨服务的用例更加困难
实现跨服务的用例需要团队间的细致协作
生产环境的部署复杂度。对于包含多种不同服务类型的系统，部署和管理的操作复杂度仍然存在。
内存消耗增加。微服务架构使用NxM个服务实例来替代N个一体应用实例。如果每个服务运行在自己独立的JVM(或类似)上，通常有必要对实例进行隔离，对这么多运行的JVN，就有M倍的开销。另外，如果每个服务运行在独立的VM(如EC2实例)，如Netflix，开销会更高。
使用该方法的一个挑战就是决定何时使用才合理。在开发应用的初期，你通常不会遇到这种方法试图解决的问题。而且，使用这个精细、分布式的架构将会拖慢开发进度。对初创公司，这是个严重问题，因为它们的最大挑战通常是如何快速发展业务模型及相关应用。使用Y轴切分使快速迭代更加困难。但是之后，当挑战变成如何伸缩，你需要使用功能分解将一体应用切分为一组服务时，混乱的依赖关系可能使之变得困难。
另一个挑战是如何将系统分隔为微服务。这是个技术活，但有些策略可能有帮助。一种方法是通过动词或用例来分隔。比如，之后你将看到分隔后的电子商务应用有个负责派送已完成订单的Shipping服务。另一个通过动词分隔的例子是实现登录用例的登录服务。
另一种分隔方法是通过名称或资源来分隔系统。这种服务负责对给定类型的实体/资源的所有操作。比如，之后你会发现为何电子商务系统有个Inventory服务来跟踪产品是否在库存中。
理论上，每个服务应该只承担很小的职责。Bob Martin(大叔)讲过使用单一职责原则(SRP)来设计类。SRP定义类的职责作为变化的原因，而且类应该只有一个变化的原因。使用SRP来设计服务也是合理的。
另一个有助于服务设计的类比是Unix实用工具的设计方法。Unix提供大量的实用工具如grep、cat和find。每个工具只做一件事，通常做得非常好，并且可以跟其他工具使用shell脚本组合来执行复杂任务。
一体架构是个替代模式。API网关模式 定义了客户端如何访问服务。
大多数大规模的web站点，如 Netflix, Amazon和eBay都从一体架构转变为微服务架构。
Netflix是个非常受欢迎的视频流服务提供商，占有多达30%的互联网流量，它有着大规模、基于服务的架构。他们每天处理800+不同类型设备超过10亿次视频流API的请求。每个API可以展开成平均6次对后端服务的调用。
Amazon.com原有个两层架构。为了伸缩，他们迁移到一个包含上百个后端服务的基于服务的架构。调用这些服务的应用中包括实现Amazon.com网站和web service API的应用。Amazon.com网站应用调用100-150个服务来获取数据用于构建网页。
拍卖网站ebay.com也从一体架构发展成基于服务的架构。应用层包含多个独立的应用。每个应用实现特定功能模块(如购买或销售)的业务逻辑。每个应用使用X轴的分隔，有些应用如搜索，使用Z轴分隔。Ebay.com也对数据库层采用X,Y,Z的组合伸缩方式。
注：
[1] 双披萨团队(two-pizza team)：两个披萨就可以喂饱整个团队，指团队规模很小。
前一篇一体化架构的翻译，请移步这里
[译]微服务架构(Microservices Architecture)
标签：style blog http ar io color os 使用 sp
原文地址：http://my.oschina.net/douxingxiang/blog/357425
