01 引言
学习参考资料：《企业级云原生架构：技术、服务与实践）》
应用架构经历了单体架构 、分布式架构 、SOA 、 微服务架构 、 服务网格架构 、 Serverless 架构的演进，本文来简要讲解下。
02 单体架构
单体应用（
monolith，也叫巨石应用）并不是单机应用，生产环境的单体应用通常是在一个集群环境下的多个节点部署的。
单体应用架构是指业务功能的实现全部在一个进程（process) 内完成，用户请求的接收、相关业务逻辑的调用、从数据库中获取数据等处理全部在一个进程内完成，这是一种比较传统的架构风格。
缺点：随着企业信息化的进一步发展，单体应用系统越来越复杂，规模也越来越庞大，一个大型应用系统动辄需要成百上千人的团队共同开发维护，没有一个人能够完全掌控整个系统，应用部署牵一发而动全身，每次应用上线都隐含着不确定性和全局风险，这给开发管理带来巨大的挑战。技术决策链路长，开发效率低下。。
03 分布式架构
分布式架构：技术人员以垂直拆分、水平拆分等不同手段，把一个大型单体应用系统拆分为若干独立的小应用系统，每个小应用系统由一个团队负责开发维护，团队可自主选择该应用的系统架构及技术栈，应用的发布部署也更加自由灵活，应用之间通过分布式服务的方式进行交互。进一步细分为：
- 前后端进行了分离。这样做带来很多好处：可以提高并发访问量，静态内容可以放到内容分发网络（Content Delivery Network, CDN）上，降低网络压力；多端协同（移动端、浏览器端）可以更好地复用后端代码；前端设计更加专业，能更好地提升客户的满意度。
- 后端进行了服务化的拆分。服务化的拆分是由于应用变得越来越复杂，一个应用往往需要几百人甚至上千人进行开发，开发协同成了一个很大的问题，服务化则很好地解决了这个问题。分布式架构将应用拆分为若干小的应用单元，每个小的应用单元只需要十几人甚至更小的团队，避免了上千人的大规模协同开发，大大提高了协同的效率。
缺点：随着分布式架构应用系统的水平+垂直拆分，应用系统以及服务的规模急剧上升，服务之间的相互调用关系盘根错节，系统烟囱林立、数据孤岛和应用协同又成为了企业信息化的问题。
04 SOA架构
SOA ：站在系统的角度解决了企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品。
比如：企业服务总线（
Enterprise Service Bus, ESB）以及技术规范、服务管理规范。这一步解决的核心问题是“有序”，使构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
缺点：SOA 并没有发挥出设计者预期的效果，第一，过于偏重技术，技术要求偏高；第二，实施 SOA 的都是第三方，是按照项目来实施的，很难按照企业的需求长期有效地对 SOA 的服务进行优化迭代，以达到预期的目的；第三，大家对 SOA 的理解存在偏差，以为 SOA 就是集成的工具或者流程再造的工具。
05 微服务架构
微服务架构：是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协同、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 REST API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务架构与SOA架构有本质区别，如下图：
缺点：微服务架构也存在一些明显的弊端：第一，对于采用 RPC 协议的微服务架构，不同微服务之间的调用存在协议绑定的问题；第二，开发人员除了关注业务逻辑的实现，还需要在微服务模块中处理一系列问题，比如服务注册、服务发现、服务通信、负载均衡、服务熔断、请求超时重试等，这是非常糟糕的。业务开发团队的强项在于业务理解，而不是技术。
06 服务网格架构
服务网格架构：在服务网格模式中，每个服务都配备了一个代理“sidecar”（边车），用于服务之间的通信，这些代理通常与应用程序代码一起部署，并且不会被应用程序所感知，将这些代理组织起来形成了一个轻量级网络代理矩阵，这些代理不再是孤立的组件，它们本身是一个有价值的网络。
服务网格是云原生技术栈中一个非常关键的组件。其中Istio最为出名，它提供一种简单的方式来建立已部署的服务的网络，具备负载均衡、服务到服务认证、监控等功能，而不需要改动任何服务代码，其功能如下：
- 流量管理：控制服务之间的流量和 API 调用的流向，使调用更可靠，并使网络在恶劣情况下更加健壮。
- 可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。
- 策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是配置网格，而不是修改应用程序代码。
- 服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。
优点：服务网格架构通过 sidecar将服务治理与业务解耦并下沉到基础设施层，使应用更加轻量化，让业务开发更聚焦于业务本身，以体系化、规范化的方式解决微服务架构下的各种服务治理挑战，提升了可观察性、可诊断性、治理能力和快速迭代能力。
07 Serverless 架构
Serverless（无服务器）:是一种构建和管理基于微服务架构的完整流程，允许用户在服务部署级别而不是服务器部署级别来管理应用部署，甚至可以管理某个具体功能或端口的部署，这能让开发者快速迭代，更快速地开发软件。
Serverless 是一种架构理念，其核心思想是将提供服务资源的基础设施抽象成各种服务，以API的方式提供给用户按需调用，真正做到按需伸缩、按使用收费。
Serverless 架构是传统云计算平台的延伸，是 PaaS 向更细粒度的 BaaS 和 FaaS 的发展， 例如：
- 函数即服务（FaaS）：是一项基于事件驱动的函数托管计算服务。通过函数服务，开发者只需要编写业务函数代码并设置运行的条件，无须配置和管理服务器等基础设施。函数代码运行在无状态的容器中，由事件触发且短暂易失，并完全由第三方管理，基础设施对应用开发者完全透明。函数以弹性、高可靠的方式运行，并且按实际执行资源计费，不执行则不产生费用。
- 后端即服务（BaaS）：覆盖了应用可能依赖的所有第三方服务，如云数据库、身份验证、对象存储、消息队列等服务，开发人员通过
API和由BaaS服务商提供的SDK，能够集成所需的所有后端功能，而无须构建后端应用，更不必管理虚拟机或容器等基础设施，就能确保应用的正常运行。
Serverless架构还节省了开发、运行、运维成本，用完释放，按需收费：
