1、 微服务规范关于微服务 .3概念和定义 .3组件与服务 .3去中心化和集中架构 .4围绕业务功能进行组织 .5产品不是项目 .5强化终端及弱化通道 .5分散治理 .5分散数据管理 .6基础设施自动化 .6容错性设计 .6设计改进 .6其它 .7微服务与 SOA.7多语言，多选择 .7实践标准和强制标准 .7原则 .8Availability：标准的目标 .8Production-Readiness 标准 .8Stability .8Reliability.8Scalability .9Fault Tolerance .9Catastrophe preparedness.9Performance
2、 .9Monitoring .10Documentation .10服务化架构的演进历史 .10历史 .10MVC.10RPC .10SOA.11微服务架构 .11微服务架构的开发原则 .12微服务架构的测试原则 .12微服务架构的部署原则 .13微服务架构的治理原则 .13微服务的接口原则 .14特征 .14服务的业务要素必须唯一并不具有歧义 .14服务必须在空间和时间上具有唯一性和稳定性 .14服务需要具备多态性 .15实践 .15微服务的粒度 .15微服务系统多大？ .15微服务规划与设计 .15人员角色的变化 .16挑战 .16问题 .17“轻量化”解决方案 .17安全性问题 .17系
3、统间耦合问题 .18系统可靠性问题 .18全局事务一致性问题 .18异构系统问题 .19组织需求与架构选择 .19微服务是未来吗？ .20附录 .20关于微服务概念和定义简单来说，服务的本质就是行为（业务活动）的抽象。对于 SOA，推进结构化信息标准组织（OASIS ）和开放团体（Open Group）均给出了正式定义。OASIS 将 SOA 定义为：A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domai
4、ns. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.Open Group 将 SOA 定义为：Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation. Service-or
5、ientation is a way of thinking in terms of services and service-based development and the outcomes of services.A service: Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit, provide weather data, consolidate drilling reports) Is se
6、lf-contained May be composed of other services Is a “black box” to consumers of the service业界基本的认知是，SOA 是一种架构模式，是一种面向服务的思维方式。对于服务的定义，Open Group 认为服务是一种可重复的业务活动的逻辑上的描述，是一种自包含的、可组合的“黑盒子” 。微服务在服务定义上，与传统的 SOA 差别不大，在实现上强调应用的颗粒度足够小，当然小到什么程度也是争论的一个话题。在我看来，微服务“微” 的并不是服务，其实微的是应用（后面我们会谈到，服务的颗粒度是和需求相关的，是不能随意变大
7、变小的）。组件与服务组件是指软件中独立的单元，它能独立替代和独立更新。微服务架构也使用组件库，但是它把软件拆分成服务，并认为这是主要的组织形式。我们把组件库定义为程序中相互关系、并使用内存中调用的组件，把服务定义为进程间使用如 Web 请求服务或者远程调用来相互通信的组件。（这种定义的方式与其它面向对象程序中服务对象的概念是不一样的。）把服务当成组件（而不是组件库）一个主要的原因是服务可以独立的部署。如果你的应用由多个组件库组成并跑在一个进程中，那么任何组件的变更都将导致整体应用的重新发布。但是如果由许多服务构成的应用，你可以想像的到每个服务的变更仅需要发布相应的服务。当然，这也不是绝对的，比
8、如导致服务接口的变更的更新就需要相应服务的变化，但优秀微服务构架，会尽量避免这种服务间的耦合并完善服务的交互接口。把服务当成组件的另一个考虑是这将拥有更新清晰的接口。许多开发语言并没有良好的定义公共接口的机制。通常只有文档和规范说明，让用户避免组件间会导致组件耦合的过度的依赖。不过服务由是是通过明确的远程接口调用，这个问题就很容易解决了。使用服务也有它的不足之处。远程调用比进制内部调用更消耗性能，而且远程的 API 比较粗糙，难以使用。如果由于对组件的职责进行变更，影响到跨进程间的交互，那么这操作起来也比较困难。第一个可能的特性，我们看到每个服务是运行在独立的进程上的。注意，这只是第一个可能的
9、特性。服务也可以由多个进程组成，它们是同时开发和部署的，例如服务可能用到一个应用进制和一种数据禀。去中心化和集中架构SOA 发展过程中既有无中心架构，也有集中架构，前者用于互联网企业间的交互，后者在企业内部使用。确切的讲 SOA 没有“ 去中心化”架构，只有“无中心化”架构。架构是为了实现特定的目标的，而这目标源于需求和现实，那么”无中心化“ 架构就是 SOA在互联网环境下的必然的架构选择。其实也没得可选，因为 SOA 要解决企业间的通过互联网相互访问的需求，而互联网是一个自由的无政府环境，根本就不存在一个共同认可的架构中心节点。两者对比如下：去（无）中心 集中组织形态 无政府 有政府组织能力
10、 不可能建立中心节点 可以建立中心节点协议约束 必须统一协议 可以不统一协议（成本低）安全策略 必须统一安全策略 安全策略多样化管控能力 无法做到统一管控 组织需要并可以做到统一管控其实无论是去中心还是集中架构，都是组织需要而非技术需要，需求决定技术架构。在企业内部，无论任何架构都要满足组织对管控的需求，而这种需求必须由一个统一的中心节点来提供，所以 SOA 化在组织内部大多数是以 ESB 作为基础来实现的。围绕业务功能进行组织微服务更倾向于围绕业务功能对服务结构进行划分、拆解。这样的服务，是针对业务领域有着关完整实现的软件，它包含使用接口、持久存储、以及对旬的交互。因此团队应该是跨职能的，包
11、含完整的开发技术：用户体验、数据库、以及项目管理。大型的整体型应用也可以按照业务功能进行模块化的，尽管这种例子不常见。当然，我们敦促一个大型的团队将一个构建成整体型的应用依照业务功能进行拆分。我们能看到主要问题在于，这种组件形式会导致很多的上下文依赖。如果在大量的模块边界上都存在这种大量的调用，对于团队的每个成员来说，短期内是很难记住的。此外，我们发现模块化方式需要大量的规范去强制执行，当然，大量明确的拆分也让服务组件在团队的边界中更加清晰。产品不是项目 开发组应该负责产品的整个生命周期。一个常见的证明是：Amazon 的“你编译，你运维（you build, you run it）” 的理念
12、，它要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都关注软件产品的运行情况，并与用户联系的更紧密，同时承担一些售后支持。强化终端及弱化通道微服务倾向于做如下的选择：强化终端及弱化通道。微服务的应用致力松耦合和高内聚：采用单独的业务逻辑，表现的更像经典 Unix 意义上的过滤器一样，接受请求、处理业务逻辑、返回响应。它们更喜欢简单的 REST 风格，而不是复杂的协议，如 WS 或者 BPEL 或者集中式框架。分散治理集中治理的一种好处是在单一平台上进行标准化。经验表明这种趋势的好处在缩小，因为并不是所有的问题都相同，而且解决方案并不是万能的。我们更加倾向于采用适当的工具解决适当的问题
13、，整体式的应用在一定程度上比多语言环境更有优势，但也适合所有的情况。也许分散治理普及于亚马逊“编译它，运维它”的理念。团队为他们开发的软件负全部责任，也包含 7*24 小时的运行。全责任的方式并不常见，但是我们确实发现越来越多的公司在他们的团队中所推广。分散数据管理当对概念模式下决心进行分散管理时，微服务也决定着分散数据管理。当整体式的应用使用单一逻辑数据库对数据持久化时，企业通常选择在应用的范围内使用一个数据库，这些决定也受厂商的商业权限模式驱动。微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。这种方法叫 Polyglot Persistence。你可以
14、把这种方法用在整体架构中，但是它更常见于微服务架构中。微服务音分散数据现任意味着管理数据更新。处理数据更新的常用方法是使用事务来保证不同的资源修改数据库的一致性。这种方法通常在整体架构中使用。基础设施自动化我们发现使用微服务的团队更加依赖于基础设施的自动化。容错性设计使用服务作为组件的一个结果在于应用需要有能容忍服务的故障的设计。任务服务可能因为供应商的不可靠而故障，客户端需要尽可能的优化这种场景的响应。跟整体构架相比，这是一个缺点，因为它带来的额外的复杂性。这将让微服务团队时刻的想到服务故障的情况下用户的体验。由于服务可以随时故障，快速故障检测，乃至，自动恢复变更非常重要。微服务应用把实时的
15、监控放在应用的各个阶段中，检测构架元素（每秒数据库的接收的请求数）和业务相关的指标（把分钟接收的定单数）。监控系统可以提供一种早期故障告警系统，让开发团队跟进并调查。设计改进微服务实践者，通常有不断改进设计的背景，他们把服务分解成进一步的工具。这些工具可以让应用开发者在不改变速度情况下，控制都他们的应用的需求变更。变更控制不意味首减少变更，而是使用适当的方式和工具，让它更加频繁，至少，很好让它变得可控。不论如何，当你试图软件系统拆分成组件时，你将面临着如何拆分的问题。那么我们的决定拆分我们应用的原则是什么呢？首要的因素，组件可以被独立替换和更新的，这意味着我们寻找的关键在于，我们要想象着重写一
16、个组件而不影响它们之前的协作关系。事实上，许多的微服务小组给它进一步的预期：服务应该能够报废的，而不是要长久的发展的。其它微服务与 SOA常时候我们谈的所谓“SOA”时，它与我们谈论的风格不一至，因为它通常是指在整体风格应用中的 ESB。我们发现面向服务的风格是这么的拙劣：从试图使用 ESB 隐藏复杂性， 到使用多年才认识到发费数百美元却没产生任务价值这样的失败，到集中治理模式抑制变更。而且这些问题往往很难发现。多语言，多选择整体构架通常意味着使用单一的语言，这也限制着使用技术的数量。实践标准和强制标准微服务团队倾向于避免这种通常由企业架构队伍定制的僵硬的强制标准，但是它们却非常乐于甚至推广这些开放的标准，如 HTTP、ATOM 、其它微规范。原则Availability：标准的目标衡量微服务是否成功的一个最通用的方法就是可用性(Availability)计算可用性的指标也很简单:uptime (正常服务时间 )、downtime(宕机时间) 、以及总运行时间(uptime + downtime)。尽管可用性指标很有用，但是它并不是衡量微服务的一个标准，而是这些标准要达到的目标。之所以不是一个标准法则，是因为它不能指导我们如何开发微服务。计算可用性一般使用几个 9 来表示。 99%: 允许宕机的时间为 3.65 天/ 年
