微服务架构的演变

文章目录

• 微服务架构的演变
• 单体架构（Monolithic）
• SOA 架构（Service Oriented Architecture）
• 微服务架构（MicroServices）
• 架构的演进
• 微服务&分布式关系
• 微服务&分布式理解

微服务架构的演变

引言

• 微服务是一种服务间松耦合的、每一个服务之间高度自治而且使用轻量级协议进行通讯的可持续集成部署的分布式架构体系
• 那么，微服务架构又与其它架构有何区别?

单体架构（Monolithic）

• 单体架构是最简单的软件架构，经常使用于传统的应用软件开发以及传统 Web 应用，适用于用户业务不复杂、访问量较小的时候，甚至能够将应用服务、数据库、文件服务器部署在一台服务器上（相信不少人都这么干过，^_）

• (MVC)三层设计模型（表示层、业务逻辑处理层、数据访问层）：

  • 表示层：一般理解为用于和用户交互的视图层；
  • 业务逻辑处理层：用户提交请求，通过业务逻辑层处理后，对用户请求做出响应；
  • 数据库访问层：主要用于操做数据库。

• 缺点：

  • 随着业务愈来愈复杂，单体应用代码量急剧膨胀，最终致使代码可 读性、可维护行和可扩展性得不到保证；
  • 随着用户访问量增长，单体应用的并发能力有限；
  • 随着系统代码量的剧增，当修改应用程序或者新增需求时，测试难度成指数级增加；
  • 部署效率低下（即便是一个很小的改动，也须要将全部机器上的应用所有部署一遍）， 增长运维复杂度；
  • 技术选型单一。

留白

• 在某个阳光明媚、风和日丽的日子里，使用单体架构发现很难推动需求的开发、以及日积月累的技术债，终于爆发了，不少企业开始作单体服务的拆分，拆分的方式通常有水平拆分和垂直拆分，逐渐演变出了SOA（Service Oriented Architecture）架构， SOA 一出世，便被赋予了重大使命…

SOA 架构（Service Oriented Architecture）

• SOA是个什么鬼？

  • SOA 是一种粗粒度、松耦合服务架构，服务之间经过简单、精肯定义接口进行通信，不涉及底层编程接口和通信模型。SOA 能够看做是 B/S 模型、XML（标准通用标记语言的子集）/Web Service 技术以后的天然延伸。

• 你说了这么多，但我仍是不知道SOA是个什么鬼啊？你能说的通熟易懂点儿么？

  • 单体服务若是至关于一个快餐店，老板（堪称全能）又要负责收银结算，又要负责作汉堡，又要负责端盘子，又要负责打扫，用户来了后，老板从前到后负责到底（累死我的哟）。SOA 至关于老板按需招聘了些许服务员，有职责分工，收银员负责收银，厨师负责作汉堡，保洁阿姨负责打扫（老板没事处处转悠转悠，晒晒太阳什么的，解放本身，坐等数票票）等，全部服务员须要用同一种语言交流，方便工做协调。

• 有什么优势吗？

  • 把模块（即服务）拆分，使用接口通讯，下降模块之间的耦合度；
  • 把项目拆分红若干个子项目，不一样的团队负责不一样的子项目；
  • 增长功能时只须要再增长一个子项目，调用其它系统的接口就能够；
  • 能够灵活的进行分布式部署。

• 说了这么多优势，不可能一点缺点都没有吧，不要王婆卖瓜自卖自诩哈…

  • 和单体架构相比，增长了系统复杂度，系统总体性能有较大影响;
  • 多服务数据通讯协议之间转换过程复杂，容易形成 ESB（Enterprise Service Bus）性能瓶颈。

SOA架构图

• ESB 架构

  • 简单说下， ESB 就像一根管道，用来链接各个服务节点。ESB的存在是为了集成基于不一样协议的不一样服务，ESB 作了消息的转化、解释以及路由的工做，以此来让不一样的服务互联互通;
  • 举个栗子: 当业务愈来愈复杂，调用关系乱成一团， ESB 现身梳理了梳理各类应用系统的复杂关系，调用关系就会清析不少（具体参照图片）

ESB架构图(简)

总结

• balabala… 说了一坨乱七八糟的东西以后，咱们说一说SOA 到底解决了咱们的那些问题：
  • 系统间的集成【有序】
    • 站在系统角度， 首先要解决的是各个系统之间的通讯问题， 目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现每每须要引入一些概念和规范，好比 ESB、以及技术规范、服务管理规范
  • 系统的服务化【复用】
    • 站在功能角度， 提出问题： 那么多业务就没有通用的吗？若是有，怎么抽象出通用业务逻辑，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;
  • 业务的服务化【高效】
    • 站在全局角度，前面两步都是从技术层面来解决系统调用、系统功能复用的问题，咱们须要在业务层面，目的是封装某一业务单元为服务，

微服务架构（MicroServices）

• 微服务的概念是 Martin Flower 在2014年写的一篇论文《MicroServices》中提出来的，其主要特色是：

  • 每一个服务按照业务划分；
  • 服务之间经过轻量级 API 调用；
  • 可使用不一样语言开发；
  • 可使用不一样的数据存储技术；
  • 可独立部署，服务之间互相不影响；
  • 可针对用户访问流量大的服务单独扩展，从而可以节约资源；
  • 管理自动化。

• 主要挑战：

  • 微服务粒度大小难以划分，须要设计人员对业务有很好的掌握；
  • 分布式复杂性，主要体如今分布式事务、网络延迟、系统容错等问题解决难度较大；
  • 微服务之间通讯成本较高，对微服务之间网络稳定性、通讯速度要求较高；
  • 因为微服务数量较大，运维人员运维、部署有较大的挑战

• 微服务架构和 SOA 架构很是相似,微服务只是的 SOA 升华，只不过微服务架构强调的是“业务须要完全的组件化及服务化”，原单个业务系统会被拆分为多个能够独立开发、设计、部署运行的小应用。这些小应用间经过服务化完成交互和集成。 组件表示的就是一个能够独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘同样，独立且能够更换升级而不影响其余单元。若咱们把 PC 中的各个组件以服务的方式构 建，那么这台 PC 只须要维护主板（能够理解为ESB）和一些必要的外部设备就能够。CPU、内存、硬盘等都是以组件方式提供服务，例如PC 须要调用 CPU 作计算处理，只需知道 CPU 这个组件的地址就能够了。

综上，按照咱们本身的理解，能够抽检出几个关键词来表达对微服务的理解与开展

松耦合

DDD（领域驱动设计）的思想进行设计领域模型，服务间尽可能减小同步的调用，多使用消息的方式让服务间的领域事件来进行解耦

轻量级协议

更倾向于使用 Restful 风格的 API，轻量级的协议能够很好地支持跨语言开发的服务，而且Restful 风格的API 便于理解

高度自治和持续集成

微服务能够很好得和容器技术结合，容器技术比微服务出现得晚，可是容器技术的出现让微服务的实施更加简
    便，目前 Docker 已经成为不少微服务实践的基础容器， 由于容器的特点，因此一台机器上能够部署几十个、
    几百个不一样的微服务。若是某个微服务流量压力比其余微服务大，能够在不增长机器的状况下，在一台机器上
    多分配一些该微服务的容器实例。同时，由于 Docker 的容器编排社区日渐成熟，相似 Mesos、Kubernetes 及 
    Docker 官方提供的 Swarm 均可以做为持续集成部署的技术选择

架构的演进

• 方向
  • 轻量级、灵活，甚至于 Serverless（无服务）架构
  • 单体 ——> 分层 ——> 面向服务 ——> 微服务 ——> Serverless（无服务）

微服务&分布式关系

• 微服务架构属于分布式系统吗？那必须得是啊…
• 做为一个微服务，给其余人使用，不得保证高可用啊，而后分布式就自个儿蹦出来了…
• 微服务的分布式不只仅是容器应用层面的分布式，其为了高度自治，底层的存储体系也应该互相独立，而且也不是全部的微服务都须要持久化的存储服务

微服务&分布式理解

• 怎样理解微服务中的分布式？以公司来举例说明，一个公司内，多个部门，各司其职，相互配合，各自占据一块区域，有些东西呢，只有该部门的人能使用，而有些呢，全部人都会使用，有些呢，本身部门没有，其它部门却拥有，既有专属资源，又有共享资源，同时共享资源还得考虑各类使用要求什么的，大抵是这样子
• 微服务的分布式不只仅是容器应用层面的分布式，其为了高度自治，底层的存储体系也应该互相独立，而且也不是全部的微服务都须要持久化的存储服务
• 微服务中的分布式场景除了服务自己须要有服务发现、负载均衡，微服务依赖的底层存储也会有分布式的场景：为了高可用性和性能须要处理数据库的复制、分区，而且在存储的分库状况下，微服务须要能保证分布式事务的一致性。

---

若有错误，请留言或及时联系，感谢阅读 – end –