微服务的九个核心的业务与技术特征¶

第一: 围绕业务能力构建¶

围绕业务能力构建(Organized around Business Capabilities)

这个核心技术特征，再次强调了康威定律的重要性:

它的意思是，有怎样的结构、规模和能力的团队，就会产生出对应结构、规模、能力的产品。

组织架构应为适应业务架构而调整:

如果本应该归属同一个产品内的功能，被划分在了不同的团队当中，那就必然会产生大量的跨团队沟通协作，
而跨越团队边界，无论是在管理、沟通，还是在工作安排上，都会产生更高的成本。

高效的团队，自然会针对这个情况进行改进，而当团队和产品磨合调节稳定了之后，就会拥有一致的结构。

第二: 分散治理¶

分散治理(Decentralized Governance)

这个技术特征，表达的是:

“谁家孩子谁来管”。
微服务对应的开发团队，有着直接对服务运行质量负责的责任，也应该有着不受外界干预，掌控服务各个方面的权力

微服务更加强调的是，在确实有必要进行技术异构的时候，一个开发团队应该能有选择 “不统一” 的权利。

第三: 通过服务来实现独立自治的组件¶

通过服务来实现独立自治的组件(Componentization via Services)

强调要通过 “服务”（Service）而不是 “类库”（Library）来构建组件:

是因为类库是在编译期静态链接到程序中的，会通过本地调用来提供功能，
  而服务是进程外组件，它是通过远程调用来提供功能的。

尽管远程服务有更高昂的调用成本，但这是为组件带来隔离与自治能力的必要代价。

第四: 产品化思维¶

产品化思维（Products not Projects）

产品化思维的意思就是:

我们要避免把软件研发看作是要去完成某种功能，而要把它当做是一种持续改进、提升的过程。
比如，我们不应该把运维看作就是运维团队的事，把开发看作就是开发团队的事。

开发团队应该为软件产品的整个生命周期负责。
开发者不仅应该知道软件是如何开发的，还应该知道它会如何运作、用户如何反馈，乃至售后支持工作是怎样进行的。
这里服务的用户，不一定是最终用户，也可能是消费这个服务的另外一个服务。

以前在单体的架构模式下:

程序的规模决定了我们无法让全部的开发人员，都关注到一个完整的产品，
在组织中会有开发、运维、支持等细致分工的成员，他们只关注于自己的一块工作。

但在微服务下，我们可以让团队中的每一位成员，都具有产品化思维。
因为在 “2 Pizza Tems” 的团队规模下，每一个人都了解全过程是完全有可能实现的。

第五: 数据去中心化¶

数据去中心化（Decentralized Data Management）

微服务这种架构模式也明确地提倡，数据应该按领域来分散管理、更新、维护和存储。

在单体服务中，通常一个系统的各个功能模块会使用同一个数据库，虽然这种中心化的存储确实天生就更容易避免一致性的问题，但是，同一个数据实体在不同服务的视角里，它的抽象形态往往也是不同的。

第六: 轻量级通讯机制¶

轻量级通讯机制（Smart Endpoints and Dumb Pipes）

这个弱管道（Dumb Pipes）机制，可以说几乎算是在直接指名道姓地反对 ESB、BPM 和 SOAP 等复杂的通讯机制。

如果服务需要『编码加工、业务规则转换、一致性、认证授权等』的某一种功能或能力，
那就应该在服务自己的 Endpoint（端点）上解决，而不是在通讯管道上一揽子处理。

微服务提倡的是类似于经典 Unix 过滤器那样，简单直接的通讯方式。比如说，RESTful 风格的通讯，在微服务中就是比较适合的。

第七: 容错性设计¶

容错性设计（Design for Failure）

容错性设计，是指软件架构不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实:

这个技术特征要求，在微服务的设计中，有自动的机制能够对其依赖的服务进行快速故障检测，
在持续出错的时候进行隔离，在服务恢复的时候重新联通。

所以 “断路器” 这类设施，对实际生产环境的微服务来说，并不是可选的外围组件，而是一个必须的支撑点。
如果没有容错性的设计，系统很容易就会因为一两个服务的崩溃带来的雪崩效应而被淹没。

可靠系统完全可以由会出错的服务来组成，这是微服务最大的价值所在

第八: 演进式设计¶

演进式设计（Evolutionary Design）

容错性设计承认服务会出错，而演进式设计则是承认服务会被报废淘汰:

一个良好设计的服务，应该是能够报废的，而不是期望得到长久的发展。
如果一个系统中出现不可更改、无可替代的服务，这并不能说明这个服务有多么重要，反而是系统设计上脆弱的表现。
微服务带来的独立、自治，也是在反对这种脆弱性。

第九: 基础设施自动化¶

基础设施自动化（Infrastructure Automation）

由于微服务架构下，运维的服务数量比起单体架构来说，要有数量级的增长，所以使用微服务的团队，会更加依赖于基础设施的自动化。