微服务架构

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

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据