这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
什么是架构
架构的发展历史
总的来说：单体架构-> SOA-> 微服务-> 无服务-> 云
单体架构
单体架构（Monolithic）
“单体”只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信，仅此而已。
单体架构被取代 最重要的理由是：单体系统很难兼容“Phoenix”的特性。这种架构风格潜在的观念是希望系统的每一个部件，每一处代码都尽量可靠，靠不出或少出缺陷来构建可靠系统。然而战术层面再优秀，也很难弥补战略层面的不足，单体靠高质量来保证高可靠性的思路，在小规模软件上还能运作良好，但系统规模越大，交付一个可靠的单体系统就变得越来越具有挑战性。
简单的来讲 单体结构过于要求其正确性 而且运维难度大 所以导致 为了允许程序出错，为了获得隔离、自治的能力，为了可以技术异构等目标，是继为了性能与算力之后，让程序再次选择分布式的理由。
SOA
SOA 架构（Service-Oriented Architecture）
面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。
SOA特性：
- 将应用的不同功能抽象成为服务
- 定义服务之间的通讯标准
SOA（Service-Oriented Architecture，面向服务的架构）是一种高层级的架构设计理念，可通过在网络上使用基于通用通信语言的服务接口，让软件组件可重复使用。
那么什么是服务呢？
所有业务功能都可以定义为一项服务，服务就意味着要对外提供开放的能力，当其他系统需要使用这项功能时，无须定制化开发。
服务可大可小，可简单也可复杂。例如，商品管理可以是一项服务，包括商品基本信息管理、供应商管理、入库管理等功能；而商品基本信息管理也可以作为一项独立的服务，供应商管理也可以作为一项独立的服务。到底是划分为粗粒度的服务，还是划分为细粒度的服务，需要根据企业的实际情况进行判断。
SOA 集成了独立部署和维护的服务，并允许它们相互通信和协同工作，以构建一个跨不同系统的软件应用。
那么它们是如何通信和协同工作的呢？
ESB（Enterprise Service Bus，企业服务总线）把企业中各个不同的服务连接在一起。就像计算机总线一样，把计算机的各个不同的设备连接在一起。
因为不同的服务是使用不同的技术实现的，各个独立的服务是异构的，如果没有统一的标准，则各个异构系统对外提供的接口是各式各样的。SOA 使用 ESB 来屏蔽异构系统对外提供各种不同的接口方式，以此来达到服务间高效的互联互通。ESB通过使用标准网络协议（如 SOAP、XML、JSON、MQ ）来开放服务以发送请求或访问数据，实现与各种系统间的协议转换、数据转换、透明的动态路由等功能，消除了开发人员必须从头开始进行集成的困扰。
采用 SOA 架构后，各个服务是相互独立运行的，甚至都不清楚某个服务到底有多少对其他服务的依赖，减少各个服务间的依赖和互相影响，做到了松耦合。
如果做不到松耦合，某个服务一升级，依赖它的其他服务全部故障，这样肯定是无法满足业务需求的。
微服务
微服务架构（Microservices）
微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。
微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。
微服务的起源是由 Peter Rodgers 博士于 2005 年度云计算博览会提出的微 Web 服务（Micro-Web-Service）开始，Juval Löwy 则是与他有类似的前导想法，将类别变成细粒服务（granular services），以作为微软下一阶段的软件架构，其核心想法是让服务是由类似 Unix 管道的访问方式使用，而且复杂的服务背后是使用简单 URI 来开放接口，任何服务，任何细粒都能被开放（exposed）。这个设计在 HP 的实验室被实现，具有改变复杂软件系统的强大力量。
2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程序构成的小服务，自己拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通信。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的编程语言与数据库等组件实现。
云
无服务架构（Serverless）
如果说微服务架构是分布式系统这条路的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。
人们研究分布式架构，最初是由于单台机器的性能无法满足系统的运行需要，尽管在后来架构演进过程中，容错能力、技术异构、职责划分等各方面因素都成为架构需要考虑的问题，但其中获得更好性能的需求在架构设计中依然占很大的比重。对软件研发而言，不去做分布式无疑才是最简单的，如果单台服务器的性能可以是无限的，那架构演进的结果肯定会与今天有很大的差别，分布式也好，容器化也好，微服务也好，恐怕都未必会如期出现，最起码不必一定是像今天这个样子。
无服务的愿景是让开发者只需要纯粹地关注业务，不需要考虑技术组件，后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；不需要考虑如何部署，部署过程完全是托管到云端的，工作由云端自动完成；不需要考虑算力，有整个数据中心支撑，算力可以认为是无限的；也不需要操心运维，维护系统持续平稳运行是云计算服务商的责任而不再是开发者的责任。在 UC Berkeley 的论文中，把无服务架构下开发者不再关心这些技术层面的细节，类比成当年软件开发从汇编语言踏进高级语言的发展过程，开发者可以不去关注寄存器、信号、中断等与机器底层相关的细节，从而令生产力得到极大地解放。
q1：SOA与微服务的对比
SOA 采用了 ESB 作为服务间通信的关键组件，负责服务定义、服务路由、消息转换、消息传递，一般情况下都是重量级的实现。
| SOA | 微服务 | |
|---|---|---|
| 服务粒度 | 粗粒度 | 细粒度 |
| 业务划分方式 | 水平多层 | 纵向业务划分 |
| 部署方式 | 整体部署 | 独立部署 |
| 通信方式 | 使用重量级通信方式，ESB充当服务之间通信的角色 | 使用轻量级通信方式，如HTTP RESTful |
| 服务交付 | 交付慢 | 交付快 |
| 应用场景 | 庞大、复杂、异构的企业级系统 | 快速、轻量级、基于 Web 的互联网系统 |
参考资料
码风略丑 读者见谅 --2023/2/10
