>**架构演进** ## 1. 单体架构 以前的系统大多是各个业务系统集中在一个单体的代码包中，包括现在也有部分传统公司也使用单体式的架构。比如订单、支付、商品、登录等模块全部写在一个代码包中。很多企业都是打包成war包部署到tomcat中。如下图：  ### 1.1单体的优缺点 - 优点：单体系统部署简单，只要达成一个包丢到web服务器即可 - 缺点：代码耦合性较高、任一业务出问题都会导致其他模块不可用 ## 2.SOA架构 服务导向式架构（SOA）是集成多个较大组件（一般是应用）的一种机制，它们将整体构成一个彼此协作的套件。一般来说，每个组件会从始至终执行一块完整的业务逻辑，通常包括完成整体大action所需的各种具体任务与功能。组件一般都是松耦合的，SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。如下图:  上图实现的构架是对单体的演进，各个系统拆分开来，每个模块对应自己的数据库(mysql、oracle、MongoDB、redis等不限制)。服务之间的调度依赖总线 ### 2.1 SOA的优缺点 - 优点： 1. 易维护 业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。建立在以 SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的，只需要调整业务服务流程或者修改操作即可，整个应用系统维护也简单了。 2. 可用性高 服务提供者和服务使用者的松散耦合关系上得以发挥与体现。使用者无须了解提供者的具休实现细节 3. 伸缩性提高 服务提供者可以互相彼此独立地进行调整，以满足新的服务需求 - 缺点： 1. 过于依赖总线控制，存在单点问题 2. 涉及不同系统事务一致性问题（分布式相关后续会专门来说） 3. 系统之间交互需要使用远程通信，接口开发增加工作量 ## 3.微服务架构 微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。 微服务提倡的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。如下图：  微服务之前的通信不像SOA架构模式中依赖dubbo、ebs等总线控制，系统之前可以点对点的互相负载均衡调用（平级关系），服务之前只需要了解对应的名称，不需要知道ip，应用支持水平拓展，通过网关控制系统访问和限流。具体如何实现的呢？请看后续的介绍。 ## 4.云原生架构 所谓云原生，这里引用CNCF 给出的特增 NCF给出了云原生应用的三大特征： * 容器化封装：以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。 * 动态管理：通过集中式的编排调度系统来动态的管理和调度。 * 面向微服务：明确服务间的依赖，互相解耦。 由此可见，云原生是包含微服务的，具体展示的架构图和微服务的类似，主要区别是研发主要关注业务实现，底层的监控、基础设施等云服务厂商均已提供相应的服务，当然也可自己部署，云原生目前还是依赖Kubernetes编排，Kubernetes出身于互联网行业的巨头Google公司，Kubernetes站在平台的角度考虑让问题消失