云原生架构（03）-架构

01 引言

学习参考资料：《企业级云原生架构：技术、服务与实践）》

云原生架构是“原生为云”而设计的应用架构，因此技术部分依赖于在传统云计算的 3 层概念：基础设施即服务（Infrastructure as a Service, IaaS）、平台即服务（Platform as a Service, PaaS）和软件即服务（Software as a Service, SaaS）。

云原生架构意味着更快的迭代速度、持续可用的服务、弹性伸缩及其他一些非功能特性，包括快速试错以支持产品创新的技术挑战、以用户体验为中心的交互模式挑战、移动互联网时代的流量激增挑战等。

云计算与云原生的关系图如下：

接下来针对云原生的的架构来讲下。

02 敏捷基础设施

下面看看轻量化的 IT 应用服务器发展趋势：

作为云原生应用的底座，敏捷基础设施主要为了解决传统基础设施所面临的挑战，包括以下几个方面。

• 资源利用率低：IT 部门一般会按业务高峰期的流量并加上一定的富余，然而业务高峰期可能只存在很短的时间，大部分业务平峰期或者业务低峰期期间，机器资源的利用率是非常低的，造成了资源浪费。
• 资源扩容周期长：新业务上线或者已有业务规模变大时，为了确保业务的隔离，一般无法共享已有的服务器资源，需要采购新服务器，一般会在企业内部走层层审批流程，采购部署的周期长，效率低下。*
• 服务器数量暴增：由于微服务等应用架构的实施，单体架构下的服务器被拆分为虚拟机或容器，导致需要管理的节点数呈爆发性增长，传统的 IT 运维管理方式面临巨大的挑战。
• 缺乏标准化：开发、测试、生产等不同环境的配置靠人工维护，人为误操作的风险使线上变更引发故障的可能性大大增加。

正如通过业务代码能够实现产品需求、通过版本化的管理能够保证业务的快速变更一样，基于云原生的开发模式也要考虑如何保证基础资源的提供能够以可编程的方式自动实现需求，并实现记录变更，保证环境的一致性。

容器技术真正实现了 IaaS 的理念落地，通过 Dockerfile 显式声明定义软件的运行环境，开发人员可以直接将所有的软件和依赖直接封装到容器中，打包成镜像，将应用和运行环境做到很好的统一，通过容器实现开发、测试、生产环境的一致，实现一次编写，到处运行的能力。

03 微服务

单体架构与微服务架构的关系图：

微服务将大型复杂软件应用拆分成多个简单应用，每个简单应用描述一个小业务，系统中的各个简单应用可以被独立部署，各个应用之间是松耦合的，每个应用仅关注完成一件任务并很好地完成该任务。

相比传统的单体架构，微服务架构具有降低系统复杂度、独立部署、独立扩展、跨语言编程等特点。

由于侵入式架构本身服务与通信组件互相依赖，当服务应用数量越来越多时，侵入式架构在服务间调用、服务发现、服务容错、服务部署、数据调用等服务治理层面将面临新的挑战。服务网格推动微服务架构进入新时代。

服务网格是一种非侵入式架构，负责应用之间的网络调用、限流、熔断和监控，可以保证应用的调用请求在复杂的微服务应用拓扑中可靠地穿梭。服务网格通常由一系列轻量级的网络代理组成（通常被称为 SideCar 模式），与应用程序部署在一起，但应用程序不需要知道它们的存在。服务网格通过服务发现、路由、负载均衡、健康检查和可观察性来帮助管理流量。

自 2017 年年初第一代服务网格架构 Linkerd 公开使用之后，Envoy、Conduit 等新框架如雨后春笋般不断诵现。2018 年年初，Google、IBM 和 Lyft 联合开发的项目 Istio 的发布，标志着服务网格带领微服务架构进入新的时代。

04 持续交付

持续交付：以一种可持续的方式安全、快速地将所有类型的更改（包括新功能、配置更改、错误修复和实验）交付到生产环境或用户手中的能力。

得益于云原生环境下的敏捷基础设施以及容器+镜像技术，对于开发人员所提交的每一次代码变更，通过工具（如 Maven、Jenkins）触发自动编译、构建、打包成镜像，自动部署到镜像仓库，持续交付服务器会将最新的镜像文件拉取到 Kubernetes集群中，并采用逐步替换容器的方式对应用进行更新，在服务不中断的前提下完成应用自动更新。整个交付过程如工厂流水线一般逐个环节往下自动触发流转，如图所示:

为了获得健康良性的持续交付效果，总结了 4 个核心工作原则：

• 【坚持少做】：小步快跑一直是互联网企业保持高速发展的制胜法宝，想办法对新业务、新创意尽早验证，通过不断反馈、迭代来演进完善我们的应用系统，而不是一次性设计一个“大而全且完美”的系统；
• 【持续分解问题】：复杂的业务问题中一定会包含很多不确定因素，它们会影响解决问题的速度和质量。通过对问题的层层分解，可以让团队了解业务，更早识别出关键问题和风险；
• 【坚持快速反馈】：需要第一时间分析和总结对已交付产品的反馈结果，了解已完成工作的质量和效果；
• 【持续改进并衡量】：任何事必须有过程、有结果，无论做了什么样的改进，如果无法以某种方式衡量它的结果，就无法证明真正得到了改进。在着手解决每个问题之前，我们都要找到恰当的衡量方式，并将其与对应的功能需求放在同等重要的位置上，一起完成。

05 DevOps

DevOps 是一套将软件开发（Development, Dev）和系统运维（Operations, Os）相结合的实践，旨在缩短应用系统开发生命周期，提供高质量的持续交付。

5.1 DevOps开发环境

一个 DevOps 开发环境需要满足以下 8 点要求：

• 【环境一致性】：在本地开发出来的功能，无论在什么环境下进行部署，都应该能得到一致的结果。
• 【代码自动检查】：每次代码提交后，系统都应该自动对代码进行检查，以便及早发现潜在的问题，并运行自动化测试。
• 【持续集成】：每次代码提交后，系统可以自动进行代码的编译和打包，无须运维人员手动进行。
• 【持续部署】：代码集成完毕后，系统可以自动将运行环境中的旧版本应用更新成新版本应用，并且整个过程中不会让系统不可用。
• 【持续反馈】：在代码自动检查、持续集成、持续部署的过程中，一旦出现问题，要能及时将问题反馈给开发人员和运维人员。开发人员和运维人员收到反馈后对问题及时进行修复。
• 【快速回滚】：当发现本次部署的版本出现问题时，系统应能快速回退到上一个可用版本。
• 【弹性伸缩】：当某个服务访问量增大时，系统应可以对这个服务快速进行扩容，保证用户的访问。当访问量回归正常时，系统能将扩容的资源释放回去，从而实现根据访问情况对系统进行弹性伸缩。
• 【可视化运维】：提供可视化的页面，可实时监控应用、集群、硬件的各种状态。

DevOps开发环境如下图：

整个环境主要由以下 6 个部分组成：

• 代码仓库：GitLab；
• 容器技术：Docker；
• 持续集成工具 ：Jenkins；
• 代码质量检测平台 ：SonarQube；
• 镜像仓库： Harbor；
• 容器集群管理系统 ：Kubernetes

5.2 与DevOps开发相关的工具

DevOps 的完整执行需要企业内部组织流程的配合和改造。不同岗位角色的人参与整个产品生命周期的不同阶段：

• 市场→需求→视觉交互→demo 原型→开发测试→集成部署→上线发布→评测反馈的完整的持续交付过程

DevOps 鼓励小团队协作，因为小团队维护少量的服务，可以快速决策、快速发布，充分利用 DevOps 的能力 ，如下图：

06 云原生应用的十二要素