拓展补充：

单体架构

单体架构：将业务的所有功能集中在一个项目中开发，最终打成一个包部署

优点：架构简单、部署成本低

缺点：耦合度高

代码之间的“边界”模糊，万一修改一处的代码，很有可能影响到其他模块的代码

分布式架构

分布式架构：根据业务功能对系统进行拆分，每个业务模块作为独立项目开发，称为一个服务

优点：

降低服务耦合
有利于服务升级

缺点：

服务要拆分
服务治理的问题：

服务拆分粒度如何？

服务集群地址如何维护？

服务之间如何实现远程调用？

服务健康状态如何感知？

面向服务的体系结构

【摘自百度】

面向服务的体系结构（service-oriented architecture）

一种包含服务提供者、服务请求者和服务中介，并且遵照开放的互操作协议来实现服务共享和组合的软件体系结构。将不同的服务通过定义良好的接口和协议联系起来，这使服务可以以一种统一和通用的方式进行交互，独立于硬件平台、操作系统和编程语言

云原生

云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系

微服务架构

微服务架构：一种经过良好架构设计的分布式架构方案

单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责，避免重复业务开发
面向服务：微服务对外暴露业务接口
自治：团队独立、技术独立、数据独立、部署独立
隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

什么是微服务？

维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建