微服务理解

“微服务架构” 用来描述将软件应用程序设计为独立可部署的组件化服务的一种特殊方式。 讨论微服务，需要先从传统单体式应用(monolith)说起。通俗地讲，“单体应用（monolith application）”就是将应用程序的所有功能都打包成一个独立的单元，可以是JAR、WAR、EAR或其它归档格式。

单体应用程序可以在业务之初取得成功，但是随着更多应用程序部署到云端，带来诸多问题:

• 更改周期连在一起 - 对应用程序的一小部分进行了更改，需要重建和部署整个整体。
• 多人共同提交一个项目，随着时间的推移，通常很难保持良好的模块化结构，难以避免更新其中某个模块的时候不对其他模块造成影响。
• 扩展需要整个应用程序的扩展，而不是需要更多资源的部分。

这些挫折导致了微服务架构风格：将应用程序构建为服务套件。 除了服务是独立可部署和可扩展的，每个服务还提供了一个稳固的模块边界，甚至允许以不同的编程语言编写不同的服务。 他们也可以由不同的团队管理。

微服务风格并非新颖的或创新的，其根源至少依赖于Unix的设计原则。

• 微服务架构的特点
  • 通过服务组件化
  • 围绕业务组建团队
  • 构建产品而非项目
  • 智能端点和笨水管（dumb pipe）
  • 权力下放治理
  • 分散式数据管理
  • 基础设施自动化
  • 为失败场景进行设计
  • 进化（升级）设计
• References
  • 原文链接
  • unix哲学
  • 软件演进

微服务架构的特点

通过服务组件化

组件是可独立更换和可升级的软件单元。组件之间通过HTTP协议或者RPC之类的机制进行通信。

• 使用服务作为组件（而不是库）的一个主要原因是服务可以独立部署。
• 更明确的组件接口，避免组件模块之间过度紧密耦合。

缺点：远程调用成本昂贵。

围绕业务组建团队

当将大型应用程序分成多个部分时，管理层往往侧重于技术层，导致UI团队，服务器端逻辑团队和数据库团队。 当团队按照这些原则分开时，会带来如下问题：

• 即使简单的更改也可能导致跨团队项目花费时间和预算的批准。
• 一个团队的个别成员(比如新员工)可能很难融入到他们的短期记忆中。
• 模块化的系列需要大量的纪律执行。

团队围绕业务来组建，由横向组织变更为垂直团队，团队是跨职能的，包括开发所需的全部技能。服务组件所需的更明确的分离使得更容易保持团队界限清晰。

构建产品而非项目

对开发人员的要求：

• 开发需要对软件的整个生命周期负责，而非完成功能开发之后交给维护团队。
• 开发人员需要增加一些运营支持负担，增加与业务用户的联系

虽说没有理由采用单一应用程序不能采用同样的方法，但是更小的服务粒度可以更容易地创建服务开发人员和用户之间的个人关系。

智能端点和笨水管（dumb pipe）

替代企业服务总线 ESB。ESB产品通常包括用于消息路由，编排，转换和应用业务规则的复杂设施，承担过多的职责。

智能端点
使用微服务思想构建的应用程序旨在尽可能地脱钩和内聚——他们拥有自己的逻辑，并且更多地采用经典Unix意义上的"过滤--接收"请求，适当地应用逻辑并产生响应。 这些是使用简单的REST协议编排的，而不是复杂的协议，如WS-Choreography或BPEL或由中央工具编排。

最常用的两种协议是使用资源API和轻量级消息传递的HTTP请求响应。 第一个的最好的表现是"成为网络，而非在网络后面"。

通过简单协议的资源，可以让开发人员更方便的进行缓存。

笨水管

通过轻量级消息总线进行消息传递。 所选择的基础设施通常是愚蠢的（像仅作为消息路由器一样愚蠢） - 诸如RabbitMQ或ZeroMQ这样的简单实现仅提供可靠的异步结构，消息的生产和消费仍然由智能端点来实现。

将整体更改为微服务的最大问题在于改变通信模式。

权力下放治理

集中治理的后果之一是将单一技术平台标准化的趋势。
通过权利下放，不对开发人员的平台和技术选型形成严格制约，团队负责他们构建的软件的所有方面，包括全天候运行软件。

这种责任水平的下放绝对不是规范，但我们确实看到越来越多的公司将责任推向开发团队。

分散式数据管理

数据管理的分散化包括如下方面：

• 概念模型决策
• 分散存储策略

微服务倾向于让每个服务管理自己的数据库。

分散管理微服务数据的责任对于管理更新具有重要意义。处理更新的常见方法是在更新多个资源时使用事务来保证一致性。这种方法通常在monolith软件中使用。使用这样的事务有助于一致性,但这在多个服务中是有问题的。分布式事务非常难以实施，因此微服务体系结构强调了服务之间的无事务协调，明确地认识到一致性只能是最终的一致性，并且通过补偿操作来处理问题。

选择以这种方式管理不一致是许多开发团队面临的新挑战，但它是经常与业务实践相匹配的挑战。企业经常处理一定程度的不一致，以便快速响应需求，同时也有一些反馈过程来处理错误。 只要修正错误的成本低于较大一致性下的业务损失，这个权衡是值得的。

基础设施自动化

• 持续交付
• 持续集成与部署 (ci --> cd)
• 自动化测试
• 自动部署

为失败场景进行设计

主要从监控以及断路器两方面进行设计：

• 应用程序需要设计，以便能够容忍服务的故障。客户端必须优雅回应服务提供者的不可用导致的失败情况。
• 由于服务可能随时出现故障，因此能够快速检测故障并尽可能自动恢复服务很重要。微服务期望为每个单独的服务以及各种操作和业务相关指标看到复杂的监控和记录设置。

在故障查理方面，微服务较之monolith引入了额外的复杂性

进化（升级）设计

组件的关键属性是独立替换和可升级性的概念。将组件置于服务中，增加了更精细的发布计划的机会。

使用整体，任何更改都需要整个应用程序的完整构建和部署。 但是，使用微服务器，只需要重新部署修改的服务。 这可以简化和加速发布过程。

不利的是，必须考虑服务升级对消费者的影响。
配合接口版本管理解决。

References

原文链接

1. Martin Fowler's mocroservice

unix哲学

• 程序应该只关注一个目标，并尽可能把它做好。
• 让程序能够互相协同工作。
• 应该让程序处理文本数据流，因为这是一个通用的接口。

更加简化的版本是：做一件事，做好它。虽然只有第三条是特指Unix系统的，但Unix开发者们常常同时强调这三个信条。

软件演进

过早的优化是一切罪恶的根源 —— Knuth

初期由于人力/时间/业务等的压力，采用monolith方式完成一版的设计开发;业务体量到达一定程度，现有软件维护成本增大之后，需要考虑服务拆分。

一个比较合理的拆分规则：2～3个人能够在2~3周完成一个系统的迭代工作。并非圭臬，但具有一定的通用性。