微服务架构

什么是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 倍的开销，另外，若是每一个服务运行在独立的虚拟机上，那么开销会更大