云原生应用架构实践

推荐序一

• 云原生与传统云计算最大的区别在于，传统云计算关注的是如何提供性价比最高的计算、存储、网络资源，而云原生关注的是

1. 如何让产品能够支持快速验证业务模式
2. 如何简化复杂的开发流程、提升研发效率
3. 如何保障产品的高可用性让业务无需承受成长之痛
4. 如何实现大规模弹性伸缩轻松应对业务爆发

内容简介

• 实现云原生应用面临的功能和非功能（高性能、高可用、可扩展、安全性、高可靠等）的不同阶段需求和实现方案进行了较为完整的梳理

第1章　互联网系统架构的挑战

1.1　云应用架构技术发展

• 简单的云主机创建也不太能满足业务的需求，后续还有大量的运维和运营工作，运维操作频率基本占比在90%以上，尤其在业务本身不断发展并且规模不断扩大的时候会更加明显，矛盾也会越来越突出

1.2　云平台下架构的不同点

• 云应用架构设计意味着更快的迭代速度、持续可用的服务、弹性扩容及一些非功能需求，包括追求产品创新时间的技术挑战、以用户体验为中心的挑战和移动互联网时代的突发性挑战

1. 更快的迭代速度
2. 持续可用的服务
3. 弹性伸缩
4. 非功能需求（云模式的产品创新、以用户体验为中心、移动互联网的突发性）

• 病毒效应在互联网场景下非常明显，因此，能够根据业务的流量和系统压力进行智能的弹性计算，也是云应用的显著特点之一，特别是在面对流量爆发或者突发事情的情况，还能保证业务的可用性，因此，业务设计的时候是否能够分析出业务的关键路径和热点部件，同时在架构层面保持足够的灵活性，以满足业务的弹性要求，并在低压力的情况下，保证资源的占用自动缩容，以减轻业务部门的成本支出；对于非核心的业务，启用避开峰值的方式来实现在线或离线业务的计算，尽可能实现云计算最大利用率，也就是常说的用好“云”，发挥云计算的最大价值

1.3　云原生应用架构

• 云原生（CloudNative）的概念，由来自Pivotal的MattStine于2013年首次提出，被一直延续使用至今。这个概念是MattStine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，内容非常多

1. DevOps
2. 持续交付（ContinuousDelivery）
3. 微服务（MicroServices）
4. 敏捷基础设施（AgileInfrastructure）
5. 12要素（TheTwelveFactorApp）

不但包括根据业务能力对公司进行文化、组织架构的重组与建设，也包括方法论与原则，还有具体的操作工具。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力

• 目前业界公认的云原生主要包括以下几个层面的内容

敏捷基础设施

• 开发人员可以随时拉取一套基础设施来服务于开发、测试、联调和灰度上线等需求

持续交付

• 为了满足业务需求频繁变动，通过快速迭代，产品能做到随时都能发布的能力，是一系列的开发实践方法。它分为持续集成、持续部署、持续发布等阶段，用来确保从需求的提出到设计开发和测试，再到让代码快速、安全地部署到产品环境中

DevOps

1. 首先，组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计
2. 其次，自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代
3. 再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作
4. DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件

微服务

• 微服务是一种架构风格，也是一种服务；其次，微服务的颗粒比较小，一个大型复杂软件应用由多个微服务组成

比如Netflix目前由500多个的微服务组成；最后，它采用UNIX设计的哲学，每种服务只做一件事，是一种松耦合的能够被独立开发和部署的无状态化服务（独立扩展、升级和可替换）

• 微服务架构如图18所示

12要素

• “12要素”英文全称是TheTwelveFactorApp，最初由Heroku的工程师整理起步，是集体贡献总结的智慧
• 基于12要素的上下文关联，软件生产就变成了一个个单一的部署单元；多个联合部署的单元组成一个应用，多个应用之间的关系就可以组成一个复杂的分布式系统应用

基准代码

• 单个应用只有一份代码库，多份部署相当于运行了该应用的多个实例，比如开发环境一个实例，测试环境、生产环境都有一个实例

依赖

• 在容器应用中，所有应用的依赖和安装都是通过DockerFile来完成声明的，通过配置能明确把依赖关系，包括版本都明确地图形化展示出来，不存在黑盒

配置

• 环境变量是一种清楚、容易理解和标准化的配置方法，将应用的配置存储于环境变量中，保证配置排除在代码之外，或者其他可能在部署环境（例如研发、展示、生产）之间区别的任何代码，可以通过操作系统级的环境变量来注入

后端服务

• 统一把依赖的后端作为一种服务来对待，例如数据库或者消息代理，作为附加资源，同等地在各种环境中被消耗

构建、发布、运行（Build-Ship-Run）

• 应用严格区分构建、发布、运行这3个阶段。3个阶段是严格分开的，一个阶段对应做一件事情，每个阶段有很明确的实现功能

进程

• 进程必须无状态且无共享，即云应用以一个或多个无状态不共享的程序运行。任何必要状态都被服务化到后端服务中（缓存、对象存储等）

端口绑定

• 在容器应用中，应用统一通过暴露端口来服务，尽量避免通过本地文件或进程来通信，每种服务通过服务发现而服务

并发

• 进程可以看作一等公民，并发性即可以依靠水平扩展应用程序来实现，通过进程模型进行扩展，并且具备无共享、水平分区的特性

云原生内容信赖关系

1. 首先，为了抓住商业机会，业务需要快速迭代，不断试错，因此，企业需要依赖拥有持续交付的能力
2. 把系统划分出一个个独立的个体，每个个体服务的设计依赖需要通过12要素的原则来规范完成
3. 如果系统被分成了几十个甚至几百个服务组件，则需要借助DevOps才能很好地满足业务协作和发布等流程
4. DevOps的有效实施需要依赖一定的土壤，即敏捷的基础设施服务，现实只有云计算的模式才能满足整体要求

• 面向云原生应用的3个不同层次的特点

1. 高可用设计（Design for Availability），不同区域、机房、机柜、服务器、进程的高可用
2. 可扩展设计（Design for Scale），所有应用设计是无状态的
3. 快速失败设计（Design for Failure），在发生异常时能够快速失败，快速恢复，以保证业务永远在线