微服务架构目前已经越来越成为行业的热门词汇，它把一种特定的软件应用的设计方法描述为能够独立部署的服务的套件。尽管缺乏对这一架构类型的准确定义，但是在业务能力、自动化部署、智能端点、语言和数据的去中心化控制等方面，已经形成了某些普遍特征。中培伟业《详细设计与系统架构最佳实践》曾老师在这里介绍了微服务架构的九大特征。

通过服务实现组件化

曾老师指出，我们已经在软件行业浸淫多年，一直期望能够通过拼插组件的方式来构建系统，而不是采用我们在物理世界里常见的方式。在过去的几十年里，我们已经见证了多数语言平台的公共库的汇编已经取得了长足的进步。

围绕业务能力组织

要把大型应用拆分为零件，管理人员通常聚焦在技术层面，拆分成 UI 组、服务器端逻辑组和数据库团组。当这些组被这样垂直分割，非常简单的改动就会导致跨组项目，而这需要时间和预算批准。聪明的团队会围绕这点进行优化，两害相权取其轻——强化逻辑到任意有访问权限的应用。

产品而非项目

大多数我们常见的应用开发会使用项目模式：交付软件的部分然后再考虑组合完整。完成后的软件被交付到维护机构，构建此项目的团队不被解散。

微服务的支持者则易于避免此模式，倾向于「在产品的整个生命周期里，开发团队应该拥有此项目」。这一灵感来自于亚马逊的「你构建，你运行」概念。在亚马逊，开发团队对生产环境中的软件负有全部责任。这让开发者每日都能了解自己的软件如何在生产环境运行，增强与用户的接触，也能承担部分支持职责。

智能终端和哑管道

要在不同进程之间构建通信结构，我们已经见过许多产品和方案，它们强调在通信机制内部注入智能，其中优秀案例如 ESB(企业服务总线)。ESB 产品包含复杂的设施，用于信息路由、编排、转化，以及应用业务规则。

去中心化治理

中心化治理的一大后果就是单一技术平台的标准化倾向。经验显示这一方式非常狭隘——每个问题各有特色，而「马斯洛的锤子」并非万能。我们更喜欢针对工作使用正确的工具，在特定情境下，一体化应用能够发挥不同语言的优势。这并不常见。

去中心化数据管理

去中心化数据管理的方式多种多样。在最为抽象的层级，这意味着各个系统之间关于世界的概念模型大相径庭。在大型企业进行整合时，这一现象很常见。对客户的看法，销售人员的视角与支持人员的视角不同。销售认为可称为「客户」的某些方面，支持人员却并不认同。他们可能只是具有一些在语言描述上差异很细微的不同属性。

使用诸如这样的事务有助于保持一致，但是带来了显著的短时耦合，对跨多个服务产生问题。分布式事务因难以实施而闻名，随之而来，微服务架构强调了服务之间的事务和谐，明确了一致性只可能为最终一致性，各种问题通过补偿运算来解决。

基础设施自动化

基础设施自动化已经在过去的几年里取得了巨大的进步。云特别是 AWS 的进化格外地降低了构建、部署和运行微服务时的复杂度。

许多采用微服务构建的产品或系统是由在持续交付和其前身——持续集成方面经验丰富的团队构建的。使用这种方法构建软件的团队需要大量使用基础设施自动化技术。

为故障而生

把服务用作组件的一个结果是应用在设计之初就要能容忍技术故障。任何服务调用可能会由于供应商的不可用而失败，而客户端需要尽可能优雅地做出响应。与一体化设计相比，由于引入了额外的复杂性来处理，这是一大不足。其结果是微服务团队不断反省服务故障如何影响用户体验。 Netflix 的 Simian Army 通过测试应用的弹性和监控，减少了工作日的服务故障，甚至数据中心的故障。

进化的设计

微服务从业者通常具有进化设计的背景，把服务分解视作一个长远的工具，让应用开发者们能够控制应用内的改动，无需让改动慢下来。改动控制并不一定意味着减少——借助正确的态度和工具，你能够经常快速、有节制地修改软件。