一、软件架构演变¶

二、单体(巨石)架构¶

传统架构（单机系统），一个项目一个工程：比如:商品、订单、支付、库存、登录、注册等等，统一部署，一个进程

all in one的架构方式，把所有的功能单元放在一个应用里。然后把整个应用部署到一台服务器上。如果负载能力不行，将整个应用进行水平复制，进行扩展，然后通过负载均衡实现访问。

Java实现：JSP、Servlet，打包成一个jar、war部署

易于开发和测试:也十分方便部署;当需要扩展时，只需要将war复制多份，然后放到多个服务器 上，再做个负载均衡就可以了。

复杂性高，在业务规模和团队规模发展的一定阶段，多个模块耦合在一起，代码结构混乱，使得团队成员无人理解整个代码逻辑。导致代码质量低，复杂性进一步增加。进一步导致重复代码越积越多。代码难以被修改和重构

可靠性差，如果某个功能模块出问题，有可能引起整个应用的崩溃。修改Bug后，某模块功能修改或升级后，需要停掉整个服务，重新整体重新打包、部署这个应用war包，功能模块相互之间耦合度高,相互影响,不适合当今互联网业务功能的快速迭代。

交付效率低，构建和部署耗时长，编译耗时变长，开发调试将大部分时间花在重新编译上，难以定位问题，开发效率低。

伸缩性(scalable)差,单体只能按整体横向扩展，无法分模块垂直扩展。

总结: 架构简单,部署方便,打包编译部署升级效率低下,各功能耦合度高,扩展困难,扩缩容不灵活,适合小型简单项目

三、MVC¶

JAVA的 MVC

MVC是模型(Model)、视图(View)、控制器(Controller)的简写，是一种软件设计规范。是将业务逻辑、数据、显示分离的方法来组织代码。MVC主要作用是降低了视图与业务逻辑间的双向偶合。

MVC不是一种设计模式，MVC是一种架构模式。当然不同的MVC存在差异。

MVC 采用template技术实现前端展示，前端和后端最终编译和整合为一个单体应用，和前后端分离方式分为两个独立项目是不同的。

• Model（模型）：数据模型，提供要展示的数据，因此包含数据和行为，可以认为是领域模型或JavaBean组件（包含数据和行为），不过现在一般都分离开来：Value Object（数据Dao） 和 服务层（行为Service）。也就是模型提供了模型数据查询和模型数据的状态更新等功能，包括数据和业务。
• View（视图）：负责进行模型的展示，一般就是我们见到的用户界面，客户想看到的东西。可通过JSP实
• Controller（控制器）：接收用户请求，委托给模型进行处理（状态改变），处理完毕后把返回的模型数据返回给视图，由视图负责展示。也就是说控制器做了个调度员的工作。最终表现为Servlet

Python的 MTV

• M: Model 数据模型，负责与数据库交互，

• T：Template 模板展示，负责呈现内容到浏览器，一般为.html文件

• V: view 流程逻辑，负责接收请求，相当于处理中枢，获取数据（来自用户） ，经过处理后选择合适的结果返回给用户。

四、SOA¶

SOA（Service Oriented Architecture）是由多个服务组成的分布式系统

各个子系统之间没有采用统一的通信标准,导致系统间通信与数据交互变得异常复杂

各个服务之间通过ESB(Enterprise Service Bus)进行通信,ESB是一个由大量规则和原则集成的软件架构，可以将一系列不同的应用程序集成到单个基础架构中，由于没有好的开源方案，只能使用商业公司的产品,因此成本很高

此外ESB属于重量级产品，部署规划异常笨重

ESB的单点依赖和商业ESB的费用问题反而成为了所有服务的瓶颈

特点: 降低服务耦合度,有利于升级扩展,服务相互访问复杂

五、微服务¶

5.1 微服务介绍¶

https://www.martinfowler.com/microservices/

简而言之，微服务架构风格是一种将单个应用程序开发为一套小型服务的方法，每个服务都在自己的进程中运行并与轻量级机制（通常是 HTTP 资源API）进行通信。这些服务围绕业务功能构建，并可通过全自动部署机制独立部署。对这些服务进行最低限度的集中管理，这些服务可能用不同的编程语言编写并使用不同的数据存储技术。-- James Lewis and Martin Fowler (2014)

亚马逊创始人 Jeff Bezos 说过一句话：“一个最好的团队用两个披萨可以喂饱”。 订单99.99%，库存99.99%一个团队控制到6-10人左右

https://wiki.mbalib.com/wiki/%E4%B8%A4%E4%B8%AA%E6%8A%AB%E8%90%A8%E5%8E%9F%E5%88%99

微服务属于SOA的子集,SOA可以认为面向服务的1.0版本,微服务可以认为是面向服务的2.0版本

微服务架构“分而治之”的手段将大型系统按业务分割成多个互相协作的微服务，每个微服务关注于自身业务职责可以独立开发、部署和维护，从而更好地应对频繁需求变更和迭代

微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底消除强耦合，每一个微服务提供单个业务功能，一个服务只做一件事。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等

从技术角度讲每个微服务就是一种小而独立的处理过程，类似与进程的概念，能够自行单独启动或销毁

微服务架构（分布式系统），各个模块/服务，各自独立出来，"让专业的人干专业的事"，独立部署。分布式系统中，不同的服务可以使用各自独立的数据库。

服务之间采用轻量级的标准的通信机制,通常是基于HTTP的RESTful (Representational State Transfer 表述性状态转移）API

微服务设计的思想改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端、后端、DBA、测试分别有自己对应的团队，属于水平团队组织架构。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。但实际上在企业中并不会把团队组织架构拆分得这么绝对，垂直架构只是一种理想的架构

微服务的实现框架有多种，不同的应用架构，部署方式也有不同

微服务特点

• 功能单一职责: 微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发

• 访问面向服务:微服务对外暴露业务接口,通过接口实现服务的访问,而不能直接访问服务内的数据和功能

• 独立自治: 团队独立、技术独立、数据独立、部署独立
• 安全性: 服务调用需要实现隔离,容错,降级等安全保护,防止级联故障

SOA 和 微服务比较

5.2 单体架构和微服务比较¶

5.3 微服务的优缺点¶

微服务优点：

• 每个服务足够内聚，足够小，代码容易理解。这样能聚焦一个简单唯一的业务功能或业务需求。
• 开发简单、开发效率提高，一个服务可能就是专业的只干一件事，所以它业务清晰，代码量较少,易于开发和维护,微服务能够被小团队单独开发，这个小团队可以是2到5人的开发人员组成
• 微服务易于被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值
• 灵活部署、独立扩展,微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件为单位进行部署。
• 相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，且易于部署
• 去中心化治理，在整个微服务架构，通过采用轻量级的契约定义接口，使得我们对服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台。
• 局部修改容易部署,单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。
• 微服务允许你利用融合最新技术。在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。微服务只是业务逻辑的代码，不会和HTML/CSS或其他界面组件混合，即前后端分
• 易于和第三方集成，微服务运行容易且灵活的方式集成自动部署，通过持续集成工具，如: Jenkins、Hudson、Bamboo
• 资源的有效隔离，每一个微服务拥有独立的数据源，假如微服务A 想要读写微服务B 的数据库，只能调用微服务B 对外暴露的接口来完成。这样有效避免了服务之间争用数据库，每个微服务都有自己的存储能力，一般都有自己的独立的数据库，也可以有统一数据库

微服务缺点：

• 微服务把原有的一个项目拆分成多个独立工程，增加了开发、测试、运维、监控等的复杂
• 微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战
• 在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录。比如对服务状态、断路器状态、吞吐量、网络延迟等关键数据进行可视化展示
• 开发人员和运维需要处理分布式系统的复杂性，需要更强的技术能
• 微服务适用于复杂的大系统，对于小型应用使用微服务，进行盲目的拆分只会增加其维护和开发成本

5.4 微服务技术栈¶

架构并不是“发明”出来的，是持续进化的结果。

只要选择了分布式架构，无论是 SOA、微服务、服务网格或者其他架构风格，都会涉及与到和远程服务交互

而服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通讯、事务处理，等等，这一系列问题都是无可避免的。

不同的架构风格，其区别是到底要在技术规范上提供统一的解决方案，还是由应用系统自行去解决，又或者在基础设施层面将一类问题隔离掉

5.5 常见的微服务框架¶

在多种编程语言中，有许多专门设计用来开发微服务的框架。以下是一些主流的微服务开发框架：

• Spring Boot & Spring Cloud：对于Java来说，Spring Boot是一个用来创建独立、基于Spring的生产级应用的框架。Spring Cloud则是一套基于Spring Boot的工具，专门用于构建分布式的、云原生的系统，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等。
• Go Kit & Micro：对于Go来说，Go Kit和Go Micro都是专门设计用来创建微服务的工具集，提供了服务发现、负载均衡、同步调用、异步消息等功能
• Django & Flask：对于Python来说，Django和Flask都是非常流行的框架，虽然它们原本并不专为微服务设计，但通过扩展和一些良好的设计实践，可以在这些框架上构建微服务
• Express.js：对于JavaScript和Node.js来说，Express.js是一个非常流行的web应用框架，常被用来创建RESTful API服务。
• .NET Core：对于.NET来说，.NET Core是一个跨平台的、开源的框架，用于构建云应用和微服务。
• Lagom：Lagom是Lightbend公司为Scala和Java设计的一种用于创建响应式微服务的开源框架。
• Akka：Akka是一个用Scala和Java编写的开源工具包和运行时，用于构建并发和分布式应用。
• gRPC：gRPC是一个高性能、开源的通用远程过程调用（RPC）框架，由Google开发并开源，适合构建微服务。

5.6 Spring Cloud¶

2008年以后，国内互联网行业飞速发展，企业对软件系统的需求已经不再是过去”能用就行”这种很低的档次了，像抢红包、双十一这样的活动不断逼迫技术人员去突破软件系统的性能上限，传统的IT企业”能用就行”的开发思想已经不能满足互联网高并发、大流量的性能要求。系统架构走向分布式已经是服务器开发领域解决该问题唯一的出路，然而分布式系统由于天生的复杂度，并不像开发单体应用一样把框架一堆就能搞定，因此各大互联网公司都在投入技术力量研发自己的基础设施。这里面JAVA技术中比较有名的如阿里的开源项目dubbo, Netflix开发的一系列服务框架。

JAVA 微服务技术

Dubbo

• 阿里开源贡献给了ASF，目前已经是Apache的顶级项
• 一款高性能的Java RPC服务框架，微服务生态体系中的一个重要组件
• 将单体程序分解成多个功能服务模块，模块间使用Dubbo框架提供的高性能RPC通
• 内部协调使用 Zookeeper，实现服务注册、服务发现和服务治理

Spring cloud

• 一个完整的微服务解决方案，相当于Dubbo的超
• 微服务框架，将单体应用拆分为粒度更小的单一功能服
• 基于HTTP协议的REST风格实现模块间通
• Spring Cloud Alibaba中的Spring Cloud Alibaba Dubbo项目则是将Dubbo与Spring Cloud进行集成，使得开发者可以在SpringCloud环境中使用Dubbo的RPC能力。

Spring Cloud

官网地址: https://spring.io/projects/spring-cloud

在这种“百花齐放”、重复造轮子的状况下，必然要出现一种统一的标准来简化分布式系统的开发，Spring Cloud应运而生。

SpringCloud是目前国内使用最广泛的Java微服务框架。

SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验:

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud正是对Netflix的多个开源组件进一步的封装而成，同时又实现了和云端平台，和Spring Boot开发框架很好的集成。

Spring Cloud是一个相对比较新的微服务框架，2016年才推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架,Spring Cloud提供的全套的分布式系统解决方案。

Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，控制总线，一次性token，全居琐，leader选举，分布式session，集群状态）中快速构建的工具，使用Spring Cloud的开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。

Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。

微服务架构是一种趋势，Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

Spring Cloud 是基于 Spring Boot 的一种微服务架构开发工具，用于简化分布式系统中的常见模式，例如配置管理、服务发现、断路器、智能路由、微代理、控制总线等。以下是 Spring Cloud 的主要发展历程：

2015年：Spring Cloud 项目正式启动。这个项目的目标是简化构建在分布式系统中运行的应用程序的开发过程。其早期的版本提供了诸如配置管理、服务发现等功能，并且与 Netflix 开源工具集（如 Eureka、Hystrix 和 Zuul）的整合非常紧密。

2016年-2018年：在这段时间里，Spring Cloud 在企业中得到了广泛的应用，并且持续引入了新的特性，比如分布式跟踪（Spring CloudSleuth 和 Zipkin 的整合）、消息驱动的微服务（Spring Cloud Stream）、基于路由的服务调用（Spring Cloud Gateway）等。

2019年：Pivotal（Spring Cloud 的背后公司）被 VMware 收购，但这并没有阻止 Spring Cloud 的发展。Spring Cloud 还在继续发布新的版本，提供更多的功能，比如 Spring Cloud Function（用于简化函数式编程）和 Spring Cloud Config Server（用于集中式的配置管理）等。

2020年-2021年：Spring Cloud 进行了一些重要的更新，例如支持新的服务发现工具，如 Kubernetes 服务发现，更好地支持云原生应用的构建和部署。

https://cn.dubbo.apache.org/zh-cn/index.htm https://spring.io/projects/spring-cloud

Spring Boot 和 Spring cloud

Spring Boot和Spring Cloud是两个相互关联但又独立的项目。它们都属于Spring生态系统，用于简化和加速Java应用程序的开发过程。

Spring Boot

Spring Boot是一个用于简化和加速Java应用程序开发的框架。它是由Spring团队开发的，基于Spring框架构建的一个轻量级、开箱即用的框架。

Spring Boot旨在简化传统的Spring应用程序开发过程，通过自动配置和约定优于配置的原则，使得开发人员能够更快地构建独立的、生产级别的Spring应用程序。它提供了许多开箱即用的特性和功能，包括：

• 自动配置：Spring Boot根据应用程序的依赖和配置自动配置应用程序的各种组件，如数据源、Web服务器、安全性等。这大大简化了配置的过程。
• 起步依赖：Spring Boot提供了一系列的"起步依赖"，它们是预配置的依赖项集合，可以快速启动特定类型的应用程序。例如，使用"spring-boot-starter-web"起步依赖可以快速构建一个基于Web的应用程序
• 嵌入式服务器：Spring Boot内置了常见的嵌入式服务器，如Tomcat、Jetty和Undertow，使得应用程序可以独立运行，无需额外安装和配置外部服务器
• 简化的配置：Spring Boot使用约定优于配置的原则，通过提供合理的默认配置来简化应用程序的配置。开发人员只需关注需要修改的配置部分，而不必处理繁琐的全局配置
• Spring Boot提供了Actuator模块，可以通过HTTP或JMX暴露应用程序的健康状况、指标和其他运行时信息，便于监控和管理应用程序。

总的来说，Spring Boot使得Java开发人员能够更快速、更简单地构建独立的、生产级别的单体应用程序。它提供了许多便利的功能和特性，使得开发人员可以专注于业务逻辑的实现，而不必花费过多时间和精力在繁琐的配置和集成上。

Spring Boot是构建独立、自包含的、可以立即运行的Spring应用程序的框架。它通过提供自动配置、约定优于配置和简化的开发体验，简化了Spring应用程序的搭建和配置过程。Spring Boot减少了繁琐的配置，使得开发者可以更专注于业务逻辑的实现。Spring Boot可以独立使用，也可以与其他Spring项目一起使用。

Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud是用于构建分布式系统和微服务架构的工具集合。它提供了一系列的功能和库，用于解决分布式系统中的常见问题，如服务注册与发现、负载均衡、断路器、配置管理等。Spring Cloud构建在Spring Boot之上，并使用Spring Boot的自动配置机制来简化微服务的开发和部署。Spring Cloud提供了许多用于构建可伸缩、弹性和可靠的分布式系统的库和工具。

因此，可以说Spring Cloud是建立在Spring Boot之上的一个框架，它利用了Spring Boot的简化开发和配置的能力，为构建分布式系统提供了额外的功能和工具。使用Spring Boot和Spring Cloud可以帮助开发者更轻松地构建和部署微服务架构，并解决分布式系统开发中的常见挑战。

Spring Cloud的本质是在Spring Boot 的基础上，增加了一堆微服务相关的规范，并对应用上下文( Application Context )进行了功能增强。既然Spring Cloud是规范那么就需要去实现

目前Spring Cloud规范已有Spring官方，Spring Cloud Netflix，Spring Cloud Alibaba等实现。通过组件化的方式，Spring Cloud将这些实现整合到一起构成全家桶式的微服务技术栈。

https://spring.io/projects/spring-cloud#overview

Spring Cloud Netflix

https://github.com/Netflix | 组件名称 | 作用 | 说明 | | --- | --- | --- | | Eureka | 服务注册中心 | 2023-06-22目前已停更，和其它业务微服务一样，不做为配置中心，其自身也需要做为微服务程序员自行开发和部署 | | Ribbon | 客户端负载均衡 | 2021-08-06最后更新 | | Feign | 声明式服务调用 | 2019年后不再更新，已经被OpenFeign取代 | | Hystrix | 客户端容错保护 | 2018-11-17最后更新 | | Zuul | API服务网关 | 2024-06-26最后更新,当前持续更新中 |

Spring Cloud Alibaba

https://github.com/alibaba/spring-cloud-alibaba https://github.com/alibaba/spring-cloud-alibaba/wiki https://gitee.com/mirrors/Spring-Cloud-Alibaba/

Spring Cloud原生及其他组件

六、服务网格 Mesh¶

从软件层面独力应对微服务架构问题，发展到软、硬一体，合力应对架构问题的时代，此即为“后微服务时代”。

当虚拟化的基础设施从单个服务的容器扩展至由多个容器构成的服务集群、通信网络和存储设施时，软件与硬件的界限便已经模糊。一旦虚拟化的硬件能够跟上软件的灵活性，那些与业务无关的技术性问题便有可能从软件层面剥离，悄无声息地解决于硬件基础设施之内，让软件得以只专注业务，真正“围绕业务能力构建”团队与产品。从软件层面独力应对分布式架构所带来的各种问题，发展到应用代码与基础设施软、硬一体，合力应对架构问题的时代，现在常被媒体冠以“云原生”这个颇为抽象的名字加以宣传。云原生时代与此前微服务时代中追求的目标并没有本质改变，在服务架构演进的历史进程中，可称为“后微服务时代”。

传统 Spring Cloud 与 Kubernetes 提供的解决方案对比

Kubernetes 成为容器战争胜利者标志着后微服务时代的开端，但 Kubernetes 仍然没有能够完美解决全部的分布式问题

“不完美”的意思是，仅从功能上看，单纯的 Kubernetes 反而不如之前的 Spring Cloud 方案。这是因为有一些问题处于应用系统与基础设施的边缘，使得完全在基础设施层面中确实很难精细化地处理。

而 Spring Cloud 的解决方法比较重，学习和交付的成本比较高，需要花更多的精力关注和配置和业务无关的功能实现

为了解决这一类问题，虚拟化的基础设施很快完成了第二次进化，引入了今天被称为“服务网格”（Service Mesh）的“边车代理模式”（Sidecar Proxy）

所谓的“边车”是一种带垮斗的三轮摩托，这个场景里指的具体含义是由系统自动在服务容器（通常是指 Kubernetes 的 Pod）中注入一个通信代理服务器，相当于那个挎斗，以类似网络安全里中间人攻击的方式进行流量劫持，在应用毫无感知的情况下，悄然接管应用所有对外通信。

这个代理除了实现正常的服务间通信外（称为数据平面通信），还接收来自控制器的指令（称为控制平面通信），根据控制平面中的配置，对数据平面通信的内容进行分析处理，以实现熔断、认证、度量、监控、负载均衡等各种附加功能。这样便实现了既不需要在应用层面加入额外的处理代码，也提供了几乎不亚于程序代码的精细管理能力。

很难从概念上判定清楚一个与应用系统运行于同一资源容器之内的代理服务到底应该算软件还是算基础设施，但它对应用是透明的，不需要改动任何软件代码就可以实现服务治理，这便足够了。

服务网格在 2018 年才火起来，今天它仍然是个新潮的概念，仍然未完全成熟，甚至连 Kubernetes 也还算是个新生事物。相信未来Kubernetes 将会成为服务器端标准的运行环境，如同现在 Linux 系统

服务网格将会成为微服务之间通信交互的主流模式，把“选择什么通信协议”、“怎样调度流量”、“如何认证授权”之类的技术问题隔离于程序代码之外，取代今天 Spring Cloud 全家桶中大部分组件的功能，微服务只需要考虑业务本身的逻辑，这才是最理想的Smart Endpoints解决方案。

业务与技术完全分离，远程与本地完全透明

服务网格 Mesh 的代表技术为Istio,Envoy,Linkerd,Consul Connect,AWS App Mesh等

Kuberetes 结合 ISTIO和Envoy 是实现 Service Mesh的主流方案

服务网格 Mesh 优势

• 把原本程序员需要关注的安全策略、负载均衡。流量控制、路由选择等基础能力下沉到了底层组件中，并提供了自动恢复的能力，让开发人员只需关注业务本身即可
• 提供各类服务编排,和服务调用的一整套完整解决方案，不仅仅针对JAVA语言写的服务,可以支持任何语言
• 提供了更灵活，可观察和安全的云原生解决方案，可以适应更复杂的应用程序需求
• 结合Kubernetes的相关云原生技术是未来的发展趋势

七、无服务架构 Serverless¶

https://www.bookstack.cn/read/fenixsoft-awesome-fenix/5c3ff5eacb378ad3.md 如果说微服务架构是分布式系统这条路的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。

人们研究分布式架构，最初是由于单台机器的性能无法满足系统的运行需要，绝对意义上的无限性能必然是不存在的，但在云计算落地已有十年时间的今日，相对意义的无限性能已经成为了现实。在工业界，2012 年，Iron.io 公司率先提出了“无服务”（Serverless，应该翻译为“无服务器”才合适，但现在称“无服务”已形成习惯了）的概念，2014 年开始，亚马逊发布了名为 Lambda 的商业化无服务应用，并在后续的几年里逐步得到开发者认可，发展成目前世界上最大的无服务的运行平台；到了 2018 年，中国的阿里云、腾讯云等厂商也开始跟进，发布了旗下的无服务的产品，“无服务”已成了近期技术圈里的“新网红”之一。

无服务现在还没有一个特别权威的“官方”定义，但它的概念并没有前面各种架构那么复杂，本来无服务也是以“简单”为主要卖点的，它只涉及两块内容：后端设施（Backend）和函数（Function）。

后端设施是指数据库、消息队列、日志、存储，等等这一类用于支撑业务逻辑运行，但本身无业务含义的技术组件，这些后端设施都运行在云中，无服务中称其为“后端即服务”（Backend as a Service，BaaS）。

函数是指业务逻辑代码，这里函数的概念与粒度，都已经很接近于程序编码角度的函数了，其区别是无服务中的函数运行在云端，不必考虑算力问题，不必考虑容量规划（从技术角度可以不考虑，从计费的角度你的钱包够不够用还是要掂量一下的），无服务中称其为“函数即服务”（Function as a Service，FaaS）。

无服务的愿景是让开发者只需要纯粹地关注业务，不需要考虑技术组件，后端的技术组件是现成的，可以直接取用，没有采购、版权和选型的烦恼；不需要考虑如何部署，部署过程完全是托管到云端的，工作由云端自动完成；不需要考虑算力，有整个数据中心支撑，算力可以认为是无限的；也不需要操心运维，维护系统持续平稳运行是云计算服务商的责任而不再是开发者的责任。在 UC Berkeley 的论文中，把无服务架构下开发者不再关心这些技术层面的细节，类比成当年软件开发从汇编语言踏进高级语言的发展过程，开发者可以不去关注寄存器、信号、中断等与机器底层相关的细节，从而令生产力得到极大地解放。

无服务架构的远期前景看起来是很美好的，但是与单体架构、微服务架构不同，无服务架构有一些天生的特点决定了它现在不是，以后如果没有重大变革的话，估计也很难成为一种普适性的架构模式。无服务架构对一些适合的应用确实能够降低开发和运维环节的成本，譬如不需要交互的离线大规模计算，又譬如多数 Web 资讯类网站、小程序、公共 API 服务、移动应用服务端等都契合于无服务架构所擅长的短链接、无状态、适合事件驱动的交互形式；但另一方面，对于那些信息管理系统、网络游戏等应用，又或者说所有具有业务逻辑复杂，依赖服务端状态，响应速度要求较高，需要长连接等这些特征的应用，至少目前是相对并不适合的。这是因为无服务天生“无限算力”的假设决定了它必须要按使用量（函数运算的时间和占用的内存）计费以控制消耗算力的规模，因而函数不会一直以活动状态常驻服务器，请求到了才会开始运行，这导致了函数不便依赖服务端状态，也导致了函数会有冷启动时间，响应的性能不可能太好（目前无服务的冷启动过程大概是在数十到百毫秒级别，对于 Java 这类启动性能差的应用，甚至能到接近秒的级别）。

无论如何，云计算毕竟是大势所趋，今天信息系统建设的概念和观念，在明天都是会转变成适应云端的，Serverless+API 的设计方式可能会成为以后其中一种主流的软件形式，届时无服务还会有更广阔的应用空间。

如果说微服务架构是分布式系统这条路当前所能做到的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。虽然在顺序上将“无服务”安排到了“微服务”和“云原生”时代之后，但它们两者并没有继承替代关系，当然无服务也并不比微服务更加先进。软件开发的未来不会只存在某一种“最先进的”架构风格，多种具针对性的架构风格同时并存，是软件产业更有生命力的形态。软件开发的未来，多种架构风格将会融合互补，“分布式”与“不分布式”的边界将逐渐模糊，两条路线在云端的数据中心中交汇。今天已经能初步看见一些使用无服务的云函数去实现微服务架构的苗头了，将无服务作为技术层面的架构，将微服务视为应用层面的架构，把它们组合起来使用是完全合理可行的。以后，无论是通过物理机、虚拟机、容器，抑或是无服务云函数，都会是微服务实现方案的候选项之一。

对于架构演进的未来发展，2014 年，Martin Fowler 与 James Lewis 在《Microservices》的结束语中曾写到，他们对于微服务日后能否被大范围地推广，最多只能持有谨慎的乐观，在无服务方兴未艾的今天，与那时微服务的情况十分相近，对无服务日后的推广同样持谨慎乐观的态度。软件开发的最大挑战就在于只能在不完备的信息下决定当前要处理的问题。时至今日，依然很难预想在架构演进之路的前方，微服务和无服务之后还会出现何种形式的架构风格

Kuberetes 结合 ISTIO和Knative 是实现 Serverless 的流行的实现方案

八、微服务还是单体¶

https://martinfowler.com/bliki/MonolithFirst.html

https://www.toutiao.com/article/7173261841408360990/?log_from=c8d3dfbf573b3_1670416613668

单体在绝大部分时候是更好的选择，即单体优先

在微服务大行其道的今天，其实已经有很多大师或者有务实的研发者已经意识到微服务在研发过程中，可能不是你想要的银弹，很多时候起到了反作用。

软件大师“Martin Fowler”在2015年就提出的“单体优先”（Monolith First）的思想。

Martin Fowler发现所有成功的微服务都遵循了通用的模式：

• 几乎所有成功的微服务故事，都是从一个变得太大而被分解的单体开始的。

• 几乎所有我听说过的从头开始构建为微服务系统的系统都以严重的麻烦告终。

这种模式导致Martin Fowler的许多同事认为：“你不应该用微服务开始一个新的项目，即使你确信你的应用程序将足够大，值得这么做...”

单体优先：

• 单体允许你探索系统的复杂性和组件的边界；
• 当复杂性增加时裂变出微服务；
• 当你边界和服务管理的业务知识增加时裂变出更多的微服务。
• 直接微服务:
• 直接使用微服务架构风险太大。

微服务是一种有用的架构，但即使是它们的拥护者也说使用它们会产生显著的“微服务附加费”，这意味着它们只对更复杂的系统有用。

这种附加费，本质上是管理一套服务的成本，将拖慢团队的速度，让使用单体应用成为更简单的选择。

这成为了“单体优先”策略的有力论证，即使你认为它可能会在以后从微服务架构中受益，你也应该在最初使用单体来构建应用。

通过先建立一个单体，你可以在使用微服务设计之前弄清楚什么是正确的边界。这也给了你时间来开发更好粒度的微服务。

单体优先策略一：模块化单体

合乎逻辑的方法是仔细设计一个单体应用，注意软件内部的模块化，包括 API 边界和数据存储方式。

做好这一点之后，从单体应用转向微服务是一件相对简单的事情。

单体优先策略二：边缘剥离

一种更常见的方法是从单体开始，逐渐剥离边缘的微服务。

这种方法可以在微服务架构的核心留下一个实质性的单体。

大多数新的开发都发生在微服务中，而单体是相对静止的。

单体优先策略三：整体替换

很少有人把这种做法看成是一种值得骄傲的做法，然而把单体作为一种牺牲性的架构来建造是有好处的。

不要害怕建造一个你会丢弃的单体应用，特别是如果一个单体应用能让你快速进入市场。

单体优先策略四：粗粒度服务

从几个粗粒度的服务开始，这些服务比你最终得到的微服务要大。

使用这些粗粒度的服务来习惯与多个服务一起工作。

同时享受这样一个事实，即这种粗粒度减少了你必须做的服务间重构的数量。

然后，随着边界的稳定，分解为更细粒度的服务。

“单体优先”的思想，目前已逐渐开始成为是业界普遍共识。现在已经属于后微服务时代!

在一个人数不多、资金不是无限充裕，需要快速将产品推向市场的团队，建议使用“单体优先”的实现方式。

在很多团队中，使用微服务其实是一种Hype Driven Development（炒作/简历驱动开发），不是为了真正为了解决业务问题。

使用“单体优先”，是一个务实的选择！试想如果是你自己创业，你会是选择“单体”还是“微服务”，那么请为你的企业进行务实的选择。

九、微服务高可用的四大关键机制¶

1、熔断（Circuit Breaker）

什么是熔断？

熔断 = 像 “保险丝” 一样 阻止继续访问已经不正常的服务。

当服务 A 调用服务 B，如果 B 持续超时、失败率过高，则 A 会主动停止请求 B，直接走 fallback（降级逻辑）。

场景

A → B（报错 / 超时过多）

→ A 启动熔断，停止请求 B，避免 A 也被拖死。

像电路短路时断电，保护上游。

作用

• 防止故障蔓延
• 让系统快速失败（fail fast）
• 保护核心服务

2、降级（Fallback / Degradation）

什么是降级？

降级 = 服务功能被临时牺牲，提供一个简单但可用的结果。

通常发生在：

• 下游服务不可用（配合熔断）
• 服务压力过高
• 资源不足（CPU / 内存）
• 请求超时

举例

用户下单时，推荐系统挂了：

• 正常返回：你可能喜欢：商品 A、商品 B、商品 C
• 降级后：推荐服务不可用，暂不展示推荐

• 作用

• 保证核心链路可用

• 非核心功能可以暂时关闭
• 系统优雅退化

3、限流（Rate Limit）

什么是限流？

限流 = 控制系统的 QPS / 并发量，防止服务被压垮。

常用策略：

• 固定窗口：1 秒最多 10 个
• 漏桶算法：匀速处理
• 令牌桶算法（最常用）：允许突发，但有限速

举例：

商品详情接口 QPS 限制 100

超过 100 的请求：

429 Too Many Requests
请稍后再试

用途

• 防止流量洪峰压垮系统
• 防止恶意请求、爬虫
• 保证系统平稳输出

4、分流（Traffic Shifting / Traffic Split）

什么是分流？

分流 = 把流量按策略切分到不同服务版本或不同集群。

常见场景：

• 灰度发布（10% 流量到新版本）
• A/B Test（不同用户走不同逻辑）
• 机房分流（按区域分配流量）
• 蓝绿发布

举例

新版本只给 5% 用户体验

95% -> v1.0
5% -> v2.0

用途

• 安全发布新版本
• 多版本并行验
• 更好的用户体验实验

四者关系总结：

一句话概括

• 限流：流量太大，门口拦人
• 熔断：下游坏了，不再访问
• 降级：功能简化，保核心
• 分流：流量分配给不同版本