微服务架构

什么是MSA 
微服务架构（Microservices Architecture ，MSA） 
业界对于与微服务本身并没有一个严格的定义。James Leiws 和 Martin Flower 对微服务架构做了这样的定义： 
“微服务架构风格就像是把小的服务开发成单一应用的形式，运行在其自己的进程中，并采用轻量级的机制通信（一般是HTTP资源API）。这些服务都是围绕业务能力来构建的，通过全自动部署工具来实现独立部署。这些服务可以使用不同的编程语言和不用的数据存储技术，并保持最小化集中管理。”

MSA包含如下特征：

• 组件以服务形式来提供 
  如题， 微服务也是面相服务的
• 围绕业务功能进行组织 
  微服务更倾向于围绕业务功能对服务结构进行划分，拆解。这样的服务，是针对业务领域有关完整实现的软件，它包含使用接口，持久存储以及对应的交互，所以团队应该是跨职能的，包含完整的开发技术，用户体验，数据库以及项目管理。
• 产品不是项目 
  传统的开发模式致力于提供一些被认为是完整的软件，一旦开发完成，软件移交给维护或者实施部门，然后开发组就可以解散了。而微服务要求开发团队对软件产品的整个生命周期负责。
• 强化终端及弱化通道 
  微服务的应用致力于松耦合和高内聚，它们更喜欢简单的REST 风格，而不是复杂的协议（如WS或者BPEL或者集中式框架）或采用轻量级的消息总线（RabbitMQ 或ZeroMQ等）来发布消息
• 分散治理 
  将整体式框架中的组件拆分成不同的服务，在构建它们时将会有更多的选择。
• 分散数据管理 
  每个服务管理自己的数据库，无论是相同数据库的不同实例，或者是不同的数据库系统。
• 基础设施自动化
• 容错性设计 
  为每个应用的服务以及数据中心提供日常的故障检测和恢复
• 改进设计 
  由于设计会不断更改，微服务所提供的服务应该能够替换或者报废，而不是长久的发展。

MSA VC SOA

单体架构的列子 
应用作为一体应用部署 有一些好处 
- 易于开发——当前开发工具和IDE的目标就是支持这种一体应用的开发。 
- 易于部署——只需要将WAR 文件或目录结构放到合适的运行环境下即可。 
- 易于伸缩——只需要在负载均衡器下面运行应用的多分副本就可以伸缩。

但是这种应用一旦变大，团队增长看这种方法的缺点就越来越明显：

• 代码库庞大—–巨大一体的代码库会吓到开发者，尤其是团队新人。 应用难于理解和修改，开发速度将会减慢，模块没有硬边界，模块化也会随着时间的增加而破坏。代码质量逐渐下降。
• IDE 超载——代码库越大，IDE 越慢，开发效率越低。
• Web容器超载—–应用越大，容器启动时间越长，时间浪费在启动容器上
• 难于部署—— 对于频繁的部署，巨大的单体架构应用是个问题，更新一个组件，必须重新部署整个应用， 还会中断后台任务
• 难于伸缩 
  单体架构只能在一个维度伸缩——-虽然可以运行多个副本来伸缩，以满足业务量的增加，一些云服务还可以动态的根据负载调整应用实例数量。但是这个架构并不能通过伸缩来满足数据量的增加，每个应用实例都要访问全部数据，使得缓存低效，而且提升了内存占用和I/O 流量，不同组件所需要的资源不同，所以单体架构下，不能独立的伸缩各个组件。
• 难于调整开发规模——单体应用对整个开发规模也是障碍，一旦应用达到一个规模，将工程组织分成专注于特定功能的模块的团队同常会更有效，
• 需要一个技术栈长期投入——单体架构迫使我们开发初期选用的技术栈，很难递增式的采用更新的技术，如果使用了后期过时的平台框架， 当将应用迁移 到更好的框架上就很有挑战，甚至为了采用新的平台框架，需要重写整个应用。

微服务架构正是解决单体架构缺点的替代模式。

微服务架构例子 
一个微服务架构的应用或是多层架构，或是六角架构，并且包含 多种类型的组件。

• 表示组件（Presentation Component） 
  响应处理HTTP请求，并返回HTML 或JSON/HTML （对于Web Service API 而言）

• 业务逻辑（Business Logic ） 
  应用的业务逻辑

• 数据库访问逻辑（Database access logic） 
  数据库访问对象用于访问数据库

• 应用集成逻辑（Application integration logic） 
  消息层，如基于Spring 的集成

  这些逻辑组件分别响应应用中不同的功能模块。

最终的微服务架构解决方案

• 通过采用伸缩立方，特别是Y 轴方向上的伸缩来架构应用，将应用按功能分为一组相互协作的服务集合，每个服务实现一组有限并相关的功能
• 服务间通过HTTP/REST 等同步协议或AMQP 等异步协议进行通信。
• 服务独立开发和部署

• 每个服务为了与其他服务器解耦，都有自己的数据库。必要时，数据库间的一致性通过数据库复制机制或应用级事件来维护。

  这个方案 有一些好处：

• 每个微服务都相对较小 
  易于开发者理解 
  IDE 反应更快，开发更高效 
  Web 容器启动更快，开发更高效，提升了部署速度

• 每个服务都可以独立部署，易于频繁部署新版本的服务

• 易于伸缩开发组织结构。 我们可以对多个团队的开发工作进行组织，每个团队负责单个服务，每个团队可以独立于其他团队开发，部署和伸缩服务
• 提升故障隔离（fault） 比如，如果一个服务器存在内存泄露，那么只有该服务受影响，其他服务仍然可以处理请求。相比之下，单体架构的一个出错组件可以拖垮整个系统
• 每个服务可以独立开发和部署
• 消除了任何对技术栈的长期投入

当然这方案也有一定的弊病：

• 开发者要处理分布式系统的额外复杂度
• 开发者IDE大多是面向构建单体架构应用的，并没有显示提供对开发分布式应用的支持
• 测试更加困难
• 开发者需要实现服务间的通信机制
• 不适用分布式事务实现跨服务的用例更加困难
• 生产环境的部署复杂度高，对于包含多种不同服务类型的系统，部署和管理操作复杂度任然存在
• 内存消耗增加。微服务架构使用 N x M 个服务实例来替代N 个单体架构应用体系，如果每个服务运行在自己独立的JVM 上，通常有必要对实例进行隔离，对这么多运行的JVM， 就有M 倍的开销，另外，如果每个服务运行在独立的虚拟机上，那么开销会更大