微服务规范

微服务规范

关于微服务 (3)

概念和定义 (3)

组件与服务 (3)

去中心化和集中架构 (4)

围绕业务功能进行组织 (5)

产品不是项目 (5)

强化终端及弱化通道 (5)

分散治理 (5)

分散数据管理 (6)

基础设施自动化 (6)

容错性设计 (6)

设计改进 (6)

其它 (7)

微服务与SOA (7)

多语言，多选择 (7)

实践标准和强制标准 (7)

原则 (7)

Availability：标准的目标 (7)

Production-Readiness 标准 (8)

Stability (8)

Reliability (8)

Scalability (9)

Fault Tolerance (9)

Catastrophe preparedness (9)

Performance (9)

Monitoring (9)

Documentation (10)

服务化架构的演进历史 (10)

历史 (10)

MVC (10)

RPC (10)

SOA (11)

微服务架构 (11)

微服务架构的开发原则 (11)

微服务架构的测试原则 (12)

微服务架构的部署原则 (13)

微服务架构的治理原则 (13)

微服务的接口原则 (13)

特征 (14)

服务的业务要素必须唯一并不具有歧义 (14)

服务必须在空间和时间上具有唯一性和稳定性 (14)

服务需要具备多态性 (14)

实践 (15)

微服务的粒度 (15)

微服务系统多大？ (15)

微服务规划与设计 (15)

人员角色的变化 (16)

挑战 (16)

问题 (17)

“轻量化”解决方案 (17)

安全性问题 (17)

系统间耦合问题 (17)

系统可靠性问题 (17)

全局事务一致性问题 (18)

异构系统问题 (19)

组织需求与架构选择 (19)

微服务是未来吗？ (19)

附录 (20)

关于微服务

概念和定义

简单来说，服务的本质就是行为（业务活动）的抽象。

对于SOA，推进结构化信息标准组织（OASIS）和开放团体（Open Group）均给出了正式定义。

OASIS将SOA定义为：

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. 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-orientation 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 self-contained May be composed of other services

●Is a “black box” to consumers of the service

业界基本的认知是，SOA是一种架构模式，是一种面向服务的思维方式。对于服务的定义，Open Group认为服务是一种可重复的业务活动的逻辑上的描述，是一种自包含的、可组合的“黑盒子”。

微服务在服务定义上，与传统的SOA差别不大，在实现上强调应用的颗粒度足够小，当然小到什么程度也是争论的一个话题。在我看来，微服务“微”的并不是服务，其实微的是应用（后面我们会谈到，服务的颗粒度是和需求相关的，是不能随意变大变小的）。

组件与服务

组件是指软件中独立的单元，它能独立替代和独立更新。

微服务架构也使用组件库，但是它把软件拆分成服务，并认为这是主要的组织形式。

我们把组件库定义为程序中相互关系、并使用内存中调用的组件，把服务定义为进程间使用如Web请求服务或者远程调用来相互通信的组件。（这种定义的方式与其它面向对象程序

中服务对象的概念是不一样的。）

把服务当成组件（而不是组件库）一个主要的原因是服务可以独立的部署。如果你的应用由多个组件库组成并跑在一个进程中，那么任何组件的变更都将导致整体应用的重新发布。但是如果由许多服务构成的应用，你可以想像的到每个服务的变更仅需要发布相应的服务。当然，这也不是绝对的，比如导致服务接口的变更的更新就需要相应服务的变化，但优秀微服务构架，会尽量避免这种服务间的耦合并完善服务的交互接口。

把服务当成组件的另一个考虑是这将拥有更新清晰的接口。许多开发语言并没有良好的定义公共接口的机制。通常只有文档和规范说明，让用户避免组件间会导致组件耦合的过度的依赖。不过服务由是是通过明确的远程接口调用，这个问题就很容易解决了。

使用服务也有它的不足之处。远程调用比进制内部调用更消耗性能，而且远程的API比较粗糙，难以使用。如果由于对组件的职责进行变更，影响到跨进程间的交互，那么这操作起来也比较困难。

第一个可能的特性，我们看到每个服务是运行在独立的进程上的。注意，这只是第一个可能的特性。服务也可以由多个进程组成，它们是同时开发和部署的，例如服务可能用到一个应用进制和一种数据禀。

去中心化和集中架构

SOA发展过程中既有无中心架构，也有集中架构，前者用于互联网企业间的交互，后者在企业内部使用。

确切的讲SOA没有“去中心化”架构，只有“无中心化”架构。

架构是为了实现特定的目标的，而这目标源于需求和现实，那么”无中心化“架构就是SOA 在互联网环境下的必然的架构选择。其实也没得可选，因为SOA要解决企业间的通过互联网相互访问的需求，而互联网是一个自由的无政府环境，根本就不存在一个共同认可的架构

其实无论是去中心还是集中架构，都是组织需要而非技术需要，需求决定技术架构。在企业

内部，无论任何架构都要满足组织对管控的需求，而这种需求必须由一个统一的中心节点来提供，所以SOA化在组织内部大多数是以ESB作为基础来实现的。

围绕业务功能进行组织

微服务更倾向于围绕业务功能对服务结构进行划分、拆解。

这样的服务，是针对业务领域有着关完整实现的软件，它包含使用接口、持久存储、以及对旬的交互。因此团队应该是跨职能的，包含完整的开发技术：用户体验、数据库、以及项目管理。

大型的整体型应用也可以按照业务功能进行模块化的，尽管这种例子不常见。当然，我们敦促一个大型的团队将一个构建成整体型的应用依照业务功能进行拆分。我们能看到主要问题在于，这种组件形式会导致很多的上下文依赖。如果在大量的模块边界上都存在这种大量的调用，对于团队的每个成员来说，短期内是很难记住的。此外，我们发现模块化方式需要大量的规范去强制执行，当然，大量明确的拆分也让服务组件在团队的边界中更加清晰。

产品不是项目

开发组应该负责产品的整个生命周期。

一个常见的证明是：Amazon的“你编译，你运维（you build, you run it）”的理念，它要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都关注软件产品的运行情况，并与用户联系的更紧密，同时承担一些售后支持。

强化终端及弱化通道

微服务倾向于做如下的选择：强化终端及弱化通道。微服务的应用致力松耦合和高内聚：采用单独的业务逻辑，表现的更像经典Unix意义上的过滤器一样，接受请求、处理业务逻辑、返回响应。它们更喜欢简单的REST风格，而不是复杂的协议，如WS或者BPEL或者集中式框架。

分散治理

集中治理的一种好处是在单一平台上进行标准化。经验表明这种趋势的好处在缩小，因为并不是所有的问题都相同，而且解决方案并不是万能的。我们更加倾向于采用适当的工具解决

适当的问题，整体式的应用在一定程度上比多语言环境更有优势，但也适合所有的情况。

也许分散治理普及于亚马逊“编译它，运维它”的理念。团队为他们开发的软件负全部责任，也包含7*24小时的运行。全责任的方式并不常见，但是我们确实发现越来越多的公司在他们的团队中所推广。

分散数据管理

当对概念模式下决心进行分散管理时，微服务也决定着分散数据管理。当整体式的应用使用单一逻辑数据库对数据持久化时，企业通常选择在应用的范围内使用一个数据库，这些决定也受厂商的商业权限模式驱动。微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。这种方法叫Polyglot Persistence。你可以把这种方法用在整体架构中，但是它更常见于微服务架构中。

微服务音分散数据现任意味着管理数据更新。处理数据更新的常用方法是使用事务来保证不同的资源修改数据库的一致性。这种方法通常在整体架构中使用。

基础设施自动化

我们发现使用微服务的团队更加依赖于基础设施的自动化。

容错性设计

使用服务作为组件的一个结果在于应用需要有能容忍服务的故障的设计。

任务服务可能因为供应商的不可靠而故障，客户端需要尽可能的优化这种场景的响应。跟整体构架相比，这是一个缺点，因为它带来的额外的复杂性。这将让微服务团队时刻的想到服务故障的情况下用户的体验。

由于服务可以随时故障，快速故障检测，乃至，自动恢复变更非常重要。微服务应用把实时的监控放在应用的各个阶段中，检测构架元素（每秒数据库的接收的请求数）和业务相关的指标（把分钟接收的定单数）。监控系统可以提供一种早期故障告警系统，让开发团队跟进并调查。

设计改进

微服务实践者，通常有不断改进设计的背景，他们把服务分解成进一步的工具。这些工具可以让应用开发者在不改变速度情况下，控制都他们的应用的需求变更。变更控制不意味首减少变更，而是使用适当的方式和工具，让它更加频繁，至少，很好让它变得可控。

不论如何，当你试图软件系统拆分成组件时，你将面临着如何拆分的问题。那么我们的决定拆分我们应用的原则是什么呢？首要的因素，组件可以被独立替换和更新的，这意味着我们寻找的关键在于，我们要想象着重写一个组件而不影响它们之前的协作关系。事实上，许多的微服务小组给它进一步的预期：服务应该能够报废的，而不是要长久的发展的。

其它

微服务与SOA

常时候我们谈的所谓“SOA”时，它与我们谈论的风格不一至，因为它通常是指在整体风格应用中的ESB。

我们发现面向服务的风格是这么的拙劣：从试图使用ESB隐藏复杂性，到使用多年才认识到发费数百美元却没产生任务价值这样的失败，到集中治理模式抑制变更。而且这些问题往往很难发现。

多语言，多选择

整体构架通常意味着使用单一的语言，这也限制着使用技术的数量。

实践标准和强制标准

微服务团队倾向于避免这种通常由企业架构队伍定制的僵硬的强制标准，但是它们却非常乐于甚至推广这些开放的标准，如HTTP、ATOM、其它微规范。

原则

Availability：标准的目标

衡量微服务是否成功的一个最通用的方法就是可用性(Availability)

计算可用性的指标也很简单:

uptime (正常服务时间)、downtime(宕机时间)、以及总运行时间(uptime + downtime)。

尽管可用性指标很有用，但是它并不是衡量微服务的一个标准，而是这些标准要达到的目标。之所以不是一个标准法则，是因为它不能指导我们如何开发微服务。

计算可用性一般使用几个9来表示。

●99%: 允许宕机的时间为3.65天/年

●99.9%: 允许宕机的时间为8.76小时/年

●99.99%: 允许宕机的时间为52.56分钟/年

●99.999%: 允许宕机的时间为5.26分钟/年

Production-Readiness 标准

Production-Readiness背后隐含的含义是：产品或者服务值得信赖，它们可以满足产交互。们需要准确的衡量。标准化如果没有可操作的原则也是没有意义的，作者提出了衡量服务是否是产品级的八个原则：

stability 、 reliability、 scalability 、 fault-tolerance 、 catastrophe-preparedness 、 performance 、monitoring 、 documentation ，它们一起为微服务提供了高可用性，但是单一的原则并不能保证微服务的可用性。

Stability

微服务架构的采用为开发者提供了很大的自由度，他们可以每天增加和发布新特性，修改bug，用新技术代替旧技术，可以重写或者弃用过时的微服务。

一个稳定的微服务应该是这样子的：它的开发、发布、新技术/新特性的增加、Bug的修改、服务的停止使用以及服务的弃用都不应该影响大的微服务生态系统的稳定性。

为了避免开发过程、发布过程、更改停止弃用时出现问题，我们需要在每个过程仔细考虑，执行到位，不会影响其它服务。

Reliability

稳定性并不是唯一影响微服务可用性的因素，微服务必须保障可靠性(Reliability)。一个可靠的微服务值得它的client所信任，以及它的依赖和整个生态圈。

稳定性和解决微服务的改变带来的副作用相关，而可靠性是和信任相关，这两个原则密不可分。每一个稳定性的需求都带来可靠性的需求。

在路由routing和服务发现的处理中，为了保证可靠性，health check应该是准确的，request 和response应该送达、错误处理应该仔细的被处理。

Scalability

微服务的业务处理很少是恒定的，成功的微服务总能平稳地处理业务量的增大。不能规模扩展的微服务在业务量增大的情况下会增加服务的延迟、低可用性，极限情况下还可能导致意外事故或者停机。

一个可扩展的微服务可以同时应付大量的任务或请求。

可扩展的微服务应该能应对突然爆发的请求，比如秒杀，防止服务整体垮掉

从整个微服务系统考虑可扩展性，当服务业务量超过它的预期的时候应该报警。服务扩展的时候也会要求它的依赖能满足扩展的需求。

微服务的数据存储也必须满足可规模扩展。

Fault Tolerance

每一个微服务都应该是容错的和提供灾备。

容错和灾备的微服务应该能够承受内部错误和外部错误。内部错误可能是微服务自己导致，例如内部代码的导致的未捕获的错误，外部错误可能是数据中心的停电、错误的配置等。

Catastrophe preparedness

灾备

Performance

scalability谈论的是服务能处理多少请求(how many)，而性能performance谈论的是微服务处理这些请求的性能(how well)。

一个高性能的微服务处理处理请求很快，任务处理很高效，正确地使用资源。Monitoring

另一个保障微服务可用性的原则就是正确的服务监控。好的监控要包括三大组件：

1.所有重要的正确的日志和相关信息

2.使用图形化的显示(dashboard)

3.关键指标的告警

所有关键的监控指标，比如硬件的使用率、数据库的连接、响应时间、API的状态等，应该图形化的显示，可以直观的观察到服务的状态。

告警信息应该传达给负责的工程师，为监控指标设置合适的阈值。

告警信息应该有用，并且可以处理，通常会有对应的处理文档。

Documentation

微服务的架构会带来技术债，减少它的办法就是文档。

最好的文档包含微服务的所有的基础知识：架构图、入手和开发手册、请求流的细节、API、告警的运维手册等。

服务化架构的演进历史

历史

MVC

RPC

RPC需要解决模块之间跨进程通信的问题，不同的团队开发不同的模块，通过一个RPC框架实现远程调用，RPC框架帮业务把通信细节给屏蔽掉，但是RPC框架也有自身的缺点。RPC本身不负责服务化，例如：服务的自动发现不管、服务的应用和发布不管、服务的运维和治理也不管。没有透明化、服务化的能力，对整个应用层的侵入还是比较深的。

SOA

SOA服务化架构，企业级资产重用和异构系统间的集成对接，SOA架构的现状：在传统企业IT领域，主要是解决异构系统之间的互通和粗粒度的标准化（WebService）。互联网领域，提供一套高效支撑应用快速开发迭代的服务化架构。例如各个互联网公司自研或者开源的分布式服务框架。

微服务架构

微服务（MSA）是一种架构风格，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它有如下几个特征：

●小，且只干一件事情。

●独立部署和生命周期管理。

●异构性

●轻量级通信，RPC或者Restful。

微服务架构的拆分原则

微服务架构的实施过程中，首先遇到的最大的难题，就是它的拆分原则。

微服务拆分原则：围绕业务功能进行垂直和水平拆分。大小粒度是难点，也是团队争论的焦点。

拆分原则：

●功能完整性、职责单一性。

●粒度适中，团队可接受。

●迭代演进，非一蹴而就。

●API的版本兼容性优先考虑。

微服务架构的开发原则

以前单体架构的时候，大家需要什么，往往喜欢自己写什么，这其实是没有太严重的依赖问题。但是到了微服务时代，微服务是一个团队或者一个小组提供的，这个时候一定没有办法在某一个时刻同时把所有的服务都提供出来，“需求实现滞后”是必然存在的。

一个好的实践策略就是接口先行，语言中立，服务提供者和消费者解耦，并行开发，提升产能。无论有多少个服务，首先需要把接口识别和定义出来，然后双方基于接口进行契约驱动开发，利用Mock服务提供者和消费者，互相解耦，并行开发，实现依赖解耦。

采用契约驱动开发，如果需求不稳定或者经常变化，就会面临一个接口契约频繁变更的问题。对于服务提供者，不能因为担心接口变更而迟迟不对外提供接口，对于消费者要拥抱变更，而不是抱怨和抵触。要解决这个问题，一种比较好的实践就是管理+ 技术双管齐下：

●允许接口变更，但是对变更的频度要做严格管控。

●提供全在线的API文档服务（例如Swagger UI），将离线的API文档转成全在线、互动

式的API文档服务。

●API变更的主动通知机制，要让所有消费该API的消费者能够及时感知到API的变更。

●契约驱动测试，用于对兼容性做回归测试。

微服务架构的测试原则

微服务的测试包括单元测试、接口测试、集成测试和行为测试等，其中最重要的就是契约测试：

用微服务框架提供的Mock机制，可以分别生成模拟消费者的客户端测试桩和提供者的服务端测试桩，双方可以基于Mock测试桩对微服务的接口契约进行测试，双方都不需要等待对方功能代码开发完成，实现了并行开发和测试，提高了微服务的构建效率。基于接口的契约测试还能快速的发现不兼容的接口变更，例如修改字段类型、删除字段等。

微服务架构的部署原则

微服务的部署原则：独立部署和生命周期管理、基础设施自动化。

需要有一套类似于CI/CD的流水线来做基础设施自动化，具体可以参考Netflix开源的微服务持续交付流水线Spinnaker：

微服务架构的治理原则

微服务部署上线之后，最重要的工作就是服务治理。微服务治理原则：线上治理、实时动态生效。

微服务常用的治理策略：

●流量控制：动态、静态流控制。

●服务降级。

●超时控制。

●优先级调度。

●流量迁移。

●调用链跟踪和分析。

●服务路由。

●服务上线审批、下线通知。

●SLA策略控制。

微服务的接口原则

微服务的接口兼容性原则：技术保障、管理协同。

●制定并严格执行《微服务前向兼容性规范》，避免发生不兼容修改或者私自修改不通知

周边的情况。

●接口兼容性技术保障：例如Thrift的IDL，支持新增、修改和删除字段、字段定义位置

无关性，码流支持乱序等。

●持续交付流水线的每日构建和契约化驱动测试，能够快速识别和发现不兼容。

特征

服务的业务要素必须唯一并不具有歧义

通过引入服务元数据的概念来描述业务要素，服务元数据的引入是实现业务与技术分离的重要手段。通过服务元数据的全局唯一性来保证业务要素的全局唯一性

元数据全局唯一，所以决定了要素一致的服务是相同的

服务必须在空间和时间上具有唯一性和稳定性

服务要素元数据化后，元数据的时空唯一性就决定了服务在时空上也是唯一的。当任意两个服务，如果其定义中引用的所有元数据集合完全一致的时候，无论这两个服务的结构上有什么差异，这两个服务都是同一个服务。

服务的时空稳定性是指，服务的一旦被严肃的定义出来，那么在任何使用环境中、任何时刻其已经明确的业务要素不会被改变，任何要素的改变意味着一个新的服务被定义。比如打球含有两个要素：人和球，无论在任何时间任何地点打球都需要这两个要素；假设某个场景需要去掉球这个要素，那么需要定义一个新的服务，这个服务可以只有人这个要素，但新的服务可能就是打架了。

服务需要具备多态性

服务多态性是指，服务可以在运行时刻动态的转变为另外一个服务的特性。

实践

微服务的粒度

微服务拆分遵循了两个纬度，一个是业务服务分级化、目前定为三级（0、1、2），0 级服务为最核心，而越是核心

的业务拆分的职责越单一和正交化，实现功能的最小集，足够的简单单一对于确保稳定、性能和控制变更都有莫大益处，

边际成本递减效应明显。

微服务系统多大？

被报道的最大团队遵循亚马逊Tow Pizaa团队理念（比如，一个团队吃两个比萨就可以了。），这意味着不超过20号（一打）人。我们发现最小配置是半打的团队支撑起一打的服务。

微服务规划与设计

当我们开始考虑到底需要拆除哪些服务时，与城市规划有些类似。首先一个城市会化成几个大的片区，

每个片区承担着城市发展所需要不同功能职责（商业、居住、工业、科技等）。只有大的片区划分是不够的，

仅仅完成了顶层设计，微服务化的设计需进一步深入到这个片区到底是否需要安置一个“购物中心”或“学校”之类，

微服务化设计完成后，每个微服务的契约与主要职责就应该像“购物中心”或“学校”这样的描述那么明确了。

微服务功能职责仅仅是服务契约中的一部分，另一部分则是非功能规约。例如一个“购物中心”的确定则隐含对

周围的交通流量提出了要求，否则过于拥堵的交通压力会影响“购物中心”功能的可用性。因此当设计一个微服务的契约时，我们需要描述清楚它提供的功能职责、承诺的响应时间分布、承载的最大流量（TPS）等设计要素。

人员角色的变化

按微服务拆分系统后，按照“服务即产品”的思路，人员角色将发生变化。

普通工程师从仅仅开发功能到开发、运营服务，工作性质的转变将带来思路和关注点的变化。每个服务至少有一个工程师作为负责人，当然能力更强的人可能会负责更多的服务。

大量拆分的微服务带来开发人员交集的减少，对于大规模的团队并行开发好处明显。

而服务负责制对个人能力要求更高，自驱动和自学习能力更强的人会得到更多的成长机会，个人成长路线的发展也打开了空间。

这时团队的构成会变得类似NBA 球队的组成，工程师的角色类似球员，架构师或技术经理类似主教练，而部门经理则是球队经理。

球员只管打好球，教练负责球员训练、培养与战术安排，经理则掌握着人事权，控制着球员的薪水升迁，招聘到优秀的球员。

挑战

“除非有必要，我们不要创造新的概念”，这就是著名的奥卡姆剃刀定律“如无必要，勿增实体”。

单体应用的架构(monolithic)

很多应用的架构都是在公司初创的时候设计的，所以那时候追求的是“糙快猛”。随着公司的发展,应用需要扩大规模，增加更多的功能，这时候开发人员会发现他们被应用最初的架构所制约，比如语言的选择、可用的库、开发工具、回归测试工具等。对应用的重构都不得不受限于初始架构的制约。显然，初始架构的选择决定了应用的未来。

期望的服务：自由的语言、自由的数据库、自由的开发工具，他们是自己的王，自由的君主。经常听到的微服务设计的一个原则就是：一个微服务就干一件事情-只干一件事情-把一件事情干好，用你所想建你所要，确保它们工作即可。

是不是太理想化了？当你拥有成百上千的微服务甚至上万个微服务在运行的时候，它们之间必须无缝的交互，不应该有质量低下的服务影响整个微服务的整体，或者说影响产品的性能

和功能。如果要保证产品的整体性能和功能工作的非常好，就需要有一定的标准，它的每一个部分也得遵循这样的标准。

问题

其实，当系统架构演化为微服务架构以后，系统所面临的新问题变得和微服务解决掉的问题几乎一样多：

“轻量化”解决方案

越来越多的人标榜自己的东西是轻量级的，看来轻量级就是简单甚至粗糙的代名词。

传统SOA架构下，解决企业内部系统间应用交互问题主要的方式就是采用ESB进行连接。但在微服务架构下，由于ESB“过重”，会导致频繁的系统间交互效率大大降低，所以微服务架构回归了去中心化的点对点调用方式。但是系统拆分带来的问题，是不是能简单的用轻量点对点通讯就能解决了呢？

安全性问题

在“大”应用拆分之前，应用的安全性是整个大应用统一考虑的，比如身份认证、权限、防篡改、防抵赖、加密等等。

那么，是不是大服务拆成微服务之后，这些黑客就消失了呢？这个想法显然是无法接受的，事实上被拆分后的微服务由于维护能力和专业能力不够，使用技术杂乱等等原因，使得黑客更容易得手。

一个不设防的微服务，对于内部黑客来说，只要从浏览器模拟一个服务请求，就可以轻松的进行危险的操作。这种“轻量”我认为无异于掩耳盗铃。

系统间耦合问题

“系统之间的耦合，从来没有像今天一样多”。对于微服务架构而言，原本系统内部对象之间的交互行为，被简单粗暴的暴露到系统之间来。

如果只是简单的把系统拆开，那么原本存在于系统内部的强耦合性会更加突出的表现出来，这导致微服务的应用开发并不比传统应用更简单，相反的还会引入诸如事务一致性等原来不存在的问题。

系统可靠性问题

微服务架构引入了一个新的可靠性问题

但是当大服务被拆分成4个微应用之后，如果业务X 的入口在A 系统，而出错点在D 系统，由于各系统都是独立的A 并不知道D 出了问题（即便知道也不知道怎么处理），对于管理者来说简单的隔离D 可能是唯一能够做到的，于是会造成一连串的连锁反应，而且系统间访问都是异步的，这会在最终问题被处理之前引发大规模的错误和回滚请求。

这种强耦合导致的系统间不可靠性，其实SOA 的解决方案就是将业务X 从系统中剥离出来，将X 放到ESB 上来进行调度（理论上应该如此，先不说ESB 能否胜任）。

全局事务一致性问题

对于这样一段传统的业务代码： 1 2 3 4 5 6 7 8 9 10 try{

t.open();

a.calculate(b);

b.save();

c.mark(b);

}catch(Exception e){

t.roolback();

//出错处理和业务逻辑是分离的

}finally{

t.close();

}

我们通过传统的编程方式，可以方便的将错误处理和业务逻辑进行分离。但是，一旦将a,b,c 拆成三个系统，问题就变得非常复杂了。首先，我们无法在传统的编程语言中支持异步调用，比如调用b.save()如果是异步的那么上面的这段代码根本就不能工作；第二，即便解决了异步问题，也就是说b.save()返回后还能成功的将程序调用堆栈恢复到c.mark()之前，你依然需要在业务代码中加入错误处理的分支，也就是说b.save 出错了应该回滚之前的操作。 所以，如果用传统语言来实现这样的业务逻辑，大多数的选择是这样的： a 系统： 1 2 3 4 5 6 7 8 9 10 11 12 13 func calculate(b){

try{

t.open();

……

b.remotecall(“save”,b);

//同步调用，在b.save 中去调用

//c.mark();

if(isError(b.return))

throw new Exception(“b.save error”);

}catch(Exception e){

t.rollback();

}finally{

t.close();

}

我们可以看到，即便是同步调用也大大增大了代码的复杂度，如果是异步调用，就需要一个框架来实现，业务逻辑会被拆的七零八落难以理解和维护。而且，这段代码实在是太丑陋了，为什么要在calculate中去调用save呢？为什么要在save中调用mark呢？显然应该有更加优雅的方法来实现。

异构系统问题

技术总是不断地进步，应用总是不断地在落后，这是一个必然趋势。我们今天用业界先进的技术来搭建新的应用系统，两年之后这个昔日先进的系统就变成落后的存量系统了。所以，异构存量系统的集成问题是永恒的话题和需求，那么互联网模式这种统一技术架构，统一接口规范的大一统想法是不切实际的，除非你肯花大量的资源去不断的跟踪技术的变化，不断的投入去改造老系统的技术平台。

微服务架构适合于利用统一的技术平台新建系统，但是随着系统的发展，系统之间的异构化逐步的成主要的矛盾，这种去中心架构也将不再能够满足系统间交互的需求。

组织需求与架构选择

架构是组织需求决定的。组织需要精细的成熟的管理，就偏向权力密集的集中架构多一些；组织需要创新和快速迭代多一些，就偏向更自由的去中心架构多一些。但是，一种非黑即白的架构选择显然是不合理的，大多数的组织既需要精细成熟的管理，也需要自由奔放的创新，所以就需要一种架构能够支撑更复杂的混合需求。

微服务是未来吗？

我们不急于确认微服务是未来软件架构方向。至今为止，我们的经验与整体风格的应该中相比出来的是有优势的，但是我们意识知这样的事实，我们并没有足够的时间来证明我们的论证。

在组件化方面的任何努力，其成功都依赖于软件如何拆分成适合的组件。指出组件化的准确边界应该在那，这是非常困难的。

因此我们持这种谨慎的乐观。到目前为止，我们还没有足够认识，关于微构架能否被大范围的推广。

附录

参考资料

https://www.360docs.net/doc/623958398.html,/articles/YfYnuiA

https://https://www.360docs.net/doc/623958398.html,/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659597120&idx=1 &sn=ac0d8495a7d58728f7de7aabaccf1564&scene=21#wechat_redirect

https://www.360docs.net/doc/623958398.html,/cn/articles/service-should-be-to-release

https://www.360docs.net/doc/623958398.html,/lib/view/open1437749298256.html