[每周一更]-(第7期)：业务架构的演进

• 从架构业务方向区分：
  单体架构---->面向服务架构---->微服务

一、单体架构

就是一个大整体，所有业务逻辑，数据处理，数据库服务等都放在一起，进一步讲除了业务服务外也可以脱离服务独立出来数据库服务、文件服务，但是业务是完整的，统称单体；
整个软件就是单一的整体，彷佛一体化的机器。可以想到，软件的功能越多，单体架构就会越复杂，很多缺点也随之暴露出来。

• （1）所有功能耦合在一起，互相影响，最终难以管理；
• （2）哪怕只修改一行代码，整个软件就要重新构建和部署，成本非常高；
• （3）因为软件做成了一个整体，不可能每个功能单独开发和测试，只能整体开发和测试，导致必须采用瀑布式开发模型；
• （4）单体存在单点故障问题；
• （5）业务量大，存在单台服务器无法承载过大流量冲击；

解决以上单体的问题：通过加入加入均衡服务器，将单体部署不同服务器上，解决单体单点故障问题，但单体本身的耦合性还需要其他架构方案。
单体架构能在边缘服务上不断优化，如：消息队列、文件系统、数据库等；

二、面向服务架构（SOA - Service Oriented Architecture）

SOA（Service-Oriented Architecture，面向服务的架构）是一种高层级的架构设计理念，可通过在网络上使用基于通用通信语言的服务接口，让软件组件可重复使用。
SOA是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式进行通信。

跟单体架构不一样，面向服务架构是语言不敏感的，不同服务可以使用不同的语言和工具开发，可能需要部署在不同的系统和环境。
这意味着，面向服务架构默认运行在不同服务器上，每台服务器提供一种服务，多台服务器共同组成一个完整的网络应用。

"面向服务架构"就是把一个大型的单体程序，拆分成一个个独立服务，也就是较小的程序。每个服务都是一个独立的功能单元，承担不同的功能，服务之间通过通信协议连在一起。
这种架构有很多优点。

• （1）每种服务功能单一，相当于一个小型软件，便于开发和测试。
• （2）各个服务独立运行，简化了架构，提高了可靠性。
• （3）鼓励和支持代码重用，同一个服务可以用于多种目的。
• （4）不同服务可以单独开发和部署，便于升级。
• （5）扩展性好，可以容易地加机器、加功能，承受高负载。
• （6）不容易出现单点故障。即使一个服务失败了，不会影响到其他服务。

ESB（Enterprise Service Bus，企业服务总线）把企业中各个不同的服务连接在一起。就像计算机总线一样，把计算机的各个不同的设备连接在一起。
因为不同的服务是使用不同的技术实现的，各个独立的服务是异构的，如果没有统一的标准，则各个异构系统对外提供的接口是各式各样的。SOA 使用 ESB 来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。ESB通过使用标准网络协议（如 SOAP、XML、JSON、MQ ）来开放服务以发送请求或访问数据，实现与各种系统间的协议转换、数据转换、透明的动态路由等功能，消除了开发人员必须从头开始进行集成的困扰。
采用 SOA 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖，减少各个服务间的依赖和互相影响，做到了松耦合。
如果做不到松耦合，某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。

当然SOA，总归来说还是单体的升级版，想要架构能够更加灵活，不同部门独立开发、独立测试、独立部署，还是需要微服务入场。

三、微服务

把单体应用拆分成一个个可以独立开发、独立测试、独立部署的微服务应用，服务和服务之间通过 API 通讯，如 HTTP、GRPC、也会采用消息协议：protobuf 等
从单体到SOA再到微服务，意味着我们运维成本的成功，对颗粒度更细的服务的管理要加强。

微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。

2014年，Docker 出现了，彻底改变了软件开发的面貌。它让程序运行在容器中，每个容器可以分别设定运行环境，并且只占用很少的系统资源。

最简单的情况下，本机运行多个容器，只用一台服务器就实现了面向服务架构，这在以前是做不到的。这种实现方式就叫做微服务。

简单说，微服务就是采用容器技术的面向服务架构。它依然使用"服务"作为功能单元，但是变成了轻量级实现，不需要新增服务器，只需要新建容器（一个进程），所以才叫做"微服务"。

一个微服务就是一个独立的进程。 这个进程可以运行在本机，也可以运行在别的服务器，或者在云端（比如云服务和云函数 FaaS）。
它的特点与面向服务架构是一样的，但因为更轻量级，所以功能的解耦和服务化可以做得更彻底。而且，它可以标准化，同样的容器不管在哪里运行，结果都是一样的，所以市场上有很多 SaaS 产品，提供标准化的微服务。
正是由于微服务这些突出的优点，这几年才会变得如此流行。它和容器技术、云服务一起，一定会在未来的软件开发中，扮演越来越重要的角色。

四、SOA和微服务对比

服务粒度
SOA 的服务粒度要粗一些，而微服务的服务粒度要细一些。例如，对一个电商企业来说，商品管理系统是一个 SOA 架构中的服务；而如果采用微服务架构，则商品管理系统会被拆分为更多的服务，比如商品基本信息管理、供应商管理、入库管理等更多服务。
服务通信
SOA 采用了 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，一般情况下都是重量级的实现。微服务则使用统一的协议和格式，例如：HTTP RESTful 协议、TCP RPC 协议，不需要 ESB 这样的重量级实现。
服务交付
SOA 对服务的交付没有特殊要求，因为 SOA 更多考虑的是兼容已有的系统；微服务的架构理念则要求快速交付，相应地要求采取自动化测试、持续集成、自动化部署、自动化运维等的最佳实践。
应用场景
SOA 更加适合于庞大、复杂、异构的企业级系统。这类系统的典型特征就是很多系统已经发展多年，各个服务具有异构性，比如：采用不同的企业级技术、有的是内部开发的、有的是外部购买的，无法完全推倒重来或者进行大规模的优化和重构。因为成本和影响太大，只能采用兼容的方式进行处理，而承担兼容任务的就是 ESB。
微服务更加适合于快速、轻量级、基于 Web 的互联网系统，这类系统业务变化快，需要快速尝试、快速交付；同时基本都是基于 Web，虽然开发技术可能差异很大（例如，Java、.NET、PHP 等），但对外接口基本都是提供 HTTP RESTful 风格的接口，无须考虑在接口层进行类似 SOA 的 ESB 那样的处理。

SOA微服务服务粒度粗粒度细粒度业务划分方式水平多层纵向业务划分部署方式整体部署独立部署通信方式使用重量级通信方式，ESB充当服务之间通信的角色使用轻量级通信方式，如HTTP RESTful服务交付交付慢交付快应用场景庞大、复杂、异构的企业级系统快速、轻量级、基于 Web 的互联网系统

• 参考：https://www.ruanyifeng.com/blog/2022/04/microservice.html
• 参考：https://bbs.huaweicloud.com/blogs/315752
• 参考：https://zhuanlan.zhihu.com/p/42115757