开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程: 云原生概要介绍-云原生架构模式分析】
课程地址:https://edu.aliyun.com/course/3112075/lesson/19006
云原生概要介绍-云原生架构模式分析
内容介绍：
一、企业架构演进
二、云原生架构与传统架构对比
三、云原生架构的几种典型模式
四、典型的云原生架构反模式
一、企业架构演进
企业的应用软件服务架构是随着 IT 技术的发展层层迭代演进而来的，由最早的单体架构发展到现在的能够满足大型互联网公司每天上亿用户的请求和实施数据处理的架构模式。
单体架构是将所有的软件模块打包在一个项目中，集中部署在一个机器上，很多的模块都挤在一个大的模块上。如果服务器一旦出现问题，就意味着软件无法提供对外服务了。
对于开发者而言，那么多的模块，简单粗暴地挤在一个应用上，这使得应用的二次开发面临着巨大的挑战。随着系统模块的不断的增多，系统变得庞大，我们需要把一些模块独立出来，组成新的服务，并逐步分解成多个系统，形成了垂直式的企业 IT 架构。
垂直架构本身是有一定的模块化设计的，并且能够提供负载均衡，能够在底层实现一些数据的交互。但是，随之垂直服务的不断增加，在垂直架构下，服务与服务之间的交互和管控又迎来了新的问题。这时，又出现了一种新的架构模式，叫做 SOA 架构。
SOA 架构是一种面向服务的架构，它将应用程序不同的功能模块进行拆分，通过这些服务之间的定义良好的接口和通信协议，使得服务与服务之间互相协作起来。接口是采用中立的方式进行定义的，它的实现不依赖于平台、操作系统和编程语言。
SOA 架构的服务管控是将所有的服务提供者注册到服务中心，通过服务总线进行服务的订阅。随着企业业务的快速发展，SOA 架构迎来了新的难题。因为服务越来越多，导致企业 ESB 的压力会越来越大，致使其无法有效地进行实施数据的传输和送达。这样，企业的数据服务总线 ESB 就成为整个系统的瓶颈，SOA 架构对于企业的高速发展也显得分身乏术。微服务的架构到来使得这个问题迎刃而解。
微服务是一个能够独立发布的应用服务，因此可以作为独立组件进行升级，或者恢复度的发布，进而实现主件级别的复用。当某个微服务进行代码的升级时，对基于微服务架构开发整个大的应用的影响是比较小的。每个微服务都可以有专业的组织来单独的完成，每个微服务之间可以采用不同的技术栈、不同的编程语言去实现。相比较于 SOA 架构中的服务，微服务架构中的服务颗粒度将更加细致。
微服务的功能是比较独立的，比如用户注册、用户订单、用户订购，这些业务处理的微服务是可以独立部署的。微服务的自治是松散管理的，它不像 SOA 架构是通过企业数据总线 ESB 来集中的注册和管理。随着敏捷开发、虚拟化技术、容器技术及 DevOps 理论的实践，微服务架构得到了业界逐步的重视和广泛的应用。微服务架构也逐步成为云原生架构的典型架构。
二、云原生架构与传统架构的对比
云原生架构与传统的软件架构相比，传统的软件架构，用户不仅仅需要关注基础设施的能力及其运维，还需要采购及维护大量第三方软件以及非功能性能力。对开发人员来说，不仅增加了软件开发的负担，还降低了软件开发的效率。
云原生架构是基于云原生六大核心技术的一组架构原则和设计模式，通过借助云原生 IaaS 和 PaaS 的能力将云应用中的非业务代码部分进行最大化剥离，从而让云设施的接管应用中原有的大量非功能性（如弹性、韧性、安全、可观测性、灰度等），使业务不再有非功能性业务中断的困扰的同时，具备轻量、敏捷、高度自动化的特点。
总结来说，云原生架构相比于传统软件架构，向前迈了一大步。从业务代码中剥离了大量非功能性特性到系统底层的 IaaS 和 PaaS 中，从而使业务开发人员更聚焦在业务相关的技术实现上。通过云产商的专业化的运维来提升整个应用的底层非功能性的能力。这样，提升了企业的软件开发效率，降低了企业软件开发的成本和风险。这就是云原生架构所带来的新的软件的开发模式。
三、云原生架构的几种典型模式
云原生其实很复杂，云原生的复杂来源于它想容纳更多复杂的事物和结构，形成积累与沉淀，其本质是连接数据，将杂乱无序的数据处理为简洁有序的信息、知识乃至于智慧。但从另一个方面而言，云原生其实又很简单。因为它给终端用户带来无穷无尽便利和丰富的功能的同时，无需他们改制。复杂和简单是相对的，底层越复杂，上层就越简单。
简单的了解一下这几种云原生架构的典型模式:
第一种模式，是服务化架构模式。服务化架构是云原生时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口方式定义彼此的业务关系，以标准协议确保服务之间的彼此的互联互通。服务化架构的典型模式就是微服务化的架构模式。
第二种是 Mesh 化架构。Mesh 化架构是把中间件（比如，ITC、缓存、业务消息等）从业务中进行剥离，让中间件 SDK 与业务代码进一步的接通。从而使得中间件的升级对业务的进程没有任何的影响，让中间件对于业务的应用而言是透明的。
第三种是 Serverless 架构，它强调的是无服务，他将系统的底层都抽象出来，定义为新的服务，Serverless 将部署从运维中收走，使开发者不用关心应用在哪里运行，更不用关心装什么操作系统，怎样配置网络等等问题。从业务抽象上来看，当业务流量到来或业务实现发生时，云会自动对系统进行扩容，以应对业务涌入的高峰流量。当处理完成之后，流量平稳过渡，业务流量又恢复到一个较低水平，这时，云会自动的关闭或者调度相关的业务进程，对系统实现缩容，降低系统的运行成本，等待下一次的出发。这就把业务的整个的运行都委托给云进行管理和控制。
第四种叫做存储计算分离模式，基于开发理论，对于需要数据存储的有状态的应用而言，如何获取 C (数据的一致性)与 A (系统的可用性)以及 P （分区容错性）这三者的最佳平衡状态，这是一门技术，也是一门艺术。在云环境中为了获得更强的系统的弹性，实现系统的高可用，推荐把各类状态的数据结构化、分节化的持久化的数据都采用云存储的形式来进行保存，从而实现存储与计算的分离。
第五，是分布式事务模式。微服务的的模式提倡每一个服务使用私有的数据源，而不是像单体共享数据源，但往往大颗粒度的业务需要访问多个微服务，必然带来分布式的事务问题。如果处理不好，将会带来数据不一致的现象。架构师需要根据不同的场景选择合适的分布式的事务模式，更好的解决底层分布式的存储和数据源的问题。还有一种是可观测架构，它包括日志监控、链路追踪、监控指标三个方面。其中日志监控能够提供多个级别的详细的信息跟踪，由应用的开发者主动提供。链路请求提供一个从前端到后端的完整的调用链路的跟踪，对于分布式的场景尤为重要。监控指标则提供对整个系统量化的多维度的度量，形成了可观测的架构模式。综上所述，这就是云原生架构中的几种典型的架构模式。
四、典型的云原生架构反模式
第一、是庞大的单体应用。按原有的方式进行分发，把它部署到云原生容器里，容器进行编排，但是应用本身还是一个庞大的单体应用，带来的最大问题就是缺乏依赖的隔离，包括代码耦合带来了责任不清、模块间的接口缺乏治理，从而带来变更的影响扩散，不同模块间的开发进度和发布时间难以协调。一个子模块的不稳定会导致整个模块的都变慢。扩容时，只能整体扩容，不能对到达瓶颈的模块单独扩容，从而不能够实现更为灵活的资源调度的模式。
第二、是把单体硬拆为微服务。服务的拆分需要适度，过分服务化拆分反而会导致新架构与组织的能力不匹配，架构升级得不到技术有效的支撑。典型的例子有小规模软件的拆分、服务之间强依赖关系数据的拆分以及分布式调用导致性能的下降。针对这些问题，在课程后面的部分我们会学习如何进行微服务的设计和微服务的拆分。
第三、是缺乏自动化能力的微服务。当软件功能的服务进一步变大后，自动化缺失会带来更大的危害。由于接口的增多会带来测试用例的增加，更多的软件模块等待测试和发布。如果缺乏自动化能力的支撑就会造成软件发布的时间变长，在多个环境发布或者异地发布时更需要专家来进行处理环境差异所带来的影响。这就是缺乏自动化服务的微服务的弊端。在课程的后面,DevOps 部分会给大家做详细的讲解。
五、回顾小结
云原生的技术生态以及 CNCF 是目前云计算领域最成功的开源基金会之一，是 Kubernetes 等知名开源项目的托管基金会。
CNCF 把云原生技术分为六层。云原生的技术众多，在众多的技术里，我们最需要掌握的是云原生的六大核心技术，包括容器技术、容器编排架构、云原生微服务架构、云原生中间件、Serverless 无服务架构、DevOps 开发运维一体化。
第三部分，我们了解了云原生机构模式，云原生架构相比传统架构前进进了一大步，将业务代码中的大量非功能性特性剥离到 IaaS 和 PaaS 中，从而减少业务代码开发人员技术关注范围，开发人员关注代码，底层通过专业性平台提升用用的服务能力。
