读红帽Redhat云原生应用的构建之路白皮书(200919)

今天阅读和整理下红帽Redhat发布的云原生构建之路白皮书，该电子版本pdf文档可以在红帽官方网站搜索和下载。对于该文档重点是对我自己已有思路的一些整理，因此对于文档里面已经详细的描述的内容不会再单独拷贝和列出。

速度-数字化业务的必备要素

对于提高市场份额，数字化驱动型企业的成功机率是其他企业的 8 倍；然而，它们仍然没有达到所谓的原生数字化。-Bain调查

随着数字化业务的不断推进，各种思维创新型技术应运而生：移动设备、智能传感器、可穿戴设备、虚拟现实、聊天机器人、区块链、机器学习和其他技术。在某种程度上，这也反映出了全新数字化原生型业务的迅猛发展势头。

在这里，还是进一步阐述下对信息化和数字化两个概念的理解。

当前，随着互联网和各种新IT技术的发展，我们当前谈的更多的是传统企业从消费互联，再到产业互联，如何实现传统企业的数字化转型。那么信息化和数字化真正的区别点究竟在哪里？

在这里我们给出一个关键的区别点：

即数字化更加强调了在传统企业信息化产生的数据信息，和物品设备，和空间位置，和人之间的自动结合。而不是类似传统信息化下大量信息由人手工录入。

因此数字化下可以更加准确的通过各种物联网硬件感知设备，软件应用来实现物流，信息流，财务流之间的三流合一。这个过程是自动化完成和集成的，如果到达这个层面，基本就完成了关键的数字化转型。

即信息和数据的产生不再单纯的依赖人，而是依赖各种智能化的设备自动完成。

什么是云原生应用？

云原生是一个用来描述应用、架构、平台/基础架构和流程的形容词。只要能全面地考虑到这些要素，我们就能够以一种经济高效的工作方式来提升我们的能力，以便快速应对各种变化，并降低不可预测性。-CHRISTIAN POSTA

在前面多篇文章里面我们都谈到的云原生的概念，即云原生本身是系列的技术最佳实践和业务管理最佳实践的结合，具体如下：

• 技术类：微服务，容器技术，ServiceMesh服务网关，ServerLess无服务器化
• 业务类：持续交付，DevOps，敏捷研发，康威定律

而里面的关键我在前面也总结过，即：

云原生 = 微服务+ DevOps + 容器化PaaS

我原来的这个总结更多的是在技术层面，而少了一个重点就是业务层面，要说到业务层面，重点就是敏捷研发和康威定律。

对于康威定律，我们先来看里面谈的关键点：

• 组织沟通方式会通过系统设计表达出来
• 时间再多一件事情也不可能做的完美，但总有时间做完一件事情
• 线型系统和线型组织架构间有潜在的异质同态特性
• 大的系统组织总是比小系统更倾向于分解

对于这四点，我想表达的重点就是当我们在实施微服务和云原生转型的时候，你看起来好像是IT系统分为了多个微服务，但是更加重要的是 业务组织和团队本身需要分解为微服务，分解高度独立自治的业务团队。

每个团队都配置独立的前后端开发，需求，测试人员高度自治。

那么在拆分为多为业务团队后，如何保证原来一个大应用和产品的概念一致性或架构完整性。在这里我们提出，对于整体的产品规划和总体架构设计仍然需要集中化统一进行，然后在拆分和分配到各个微服务开发团队。

那么这里的架构设计包括哪些内容呢？具体如下：

• 各个微服务模块的功能列表清单
• 各个微服务模块的接口清单
• 数据库的拆分和数据表的Owner归属

以上三点就是最重要的架构设计需要提前进行的点。这个清楚后即可以分配到各个微服务团队，那么微服务团队高度自治和扁平化，各个团队之间之间进行协同和沟通，而不需要再通过架构师来协同增加沟通路径。

即产品规划和架构师很类似微服务架构里面的注册控制中心的职责。这也是我们常说的技术上的微服务拆分，实际上真正先行的业务组织团队的架构调整和职责拆分。

对于什么是云原生，我自己保留一个通俗理解为：

一个传统IT系统将技术基础设施和服务剥离，并为了适应云环境和服务，适应应用持续敏捷向公有云环境交付所做出的所有技术实践和业务管理实践。

你可以看到前面谈的微服务，容器，DevOps，敏捷研发等全部都是围绕这个目标而努力。

传统应用和云原生应用

对于传统应用和云原生应用的差异对比，在白皮书里面给出了一个差异对比表如下：

对于该点，我在上篇文章也给出一个完整的演进过程，如下：

最初可能 仅仅是实现虚拟化资源池，实现IaaS平台层统一 。在这个时候业务系统构建仍然是烟囱式的构建模式，每个业务系统底层有比较重的中间件和平台，业务系统是一个大的单体应用，内部各个业务模块仍然没有完全解耦。

第二阶段即我们常说的 私有云PaaS平台建设阶段 ，在这个阶段进一步实现中间件资源池，也会做类似4A，流程引擎平台的整合和统一。业务系统逐步朝组件化开发过渡和解耦，但是业务系统内部仍然存在技术平台和技术支撑。

第三阶段实际上有几个大的变化，首先就是PaaS云平台从传统比较重的类似Cloudfoundry，Cloudify已经 过渡到更加轻量高效的容器云平台，同时大量技术服务能力共性化建设 。其次是业务系统彻底实现微服务架构化和解耦。那么在上层微服务设计，开发，部署和交付过程如何与底层的容器云平台，技术服务平台进一步协同？这里面就是我们常说的DevOps过程支撑平台。

而结合差异化对比表格，我们再次给出传统应用和云原生关键区别点：

• 应用架构： 由传统单体走向微服务架构和Rest API集成
• 开发管理： 由传统开发走向敏捷研发和DevOps支撑集成和交付
• 基础设施架构： 由IaaS云走向容器化PaaS云

而这三点刚好也可以看到，通过DevOps实现应用架构和基础设施间的集成和协同。

云原生应用开发部署四大原则

云原生应用开发所构建和运行的应用，旨在充分利用基于四大原则的云计算模型：基于服务的架构、基于 API 的通信、基于容器的基础架构以及 DevOps 流程。

该书里面详细说明如下：

可以看到实际核心仍然就是我们前面谈到的微服务+容器云+DevOps，其中微服务架构里面已经包括了各个微服务模块需要通过Http Rest API接口进行通信。同时对于DevOps最佳实践里面也包括了云原生里面谈的持续交付，敏捷研发最佳实践。

云原生应用构建的八大步骤

步骤 1：发展 DEVOPS 文化和实践

要完成云原生应用的构建之路，开发和 IT 运维团队必须进行多方面的变革，以便更加快速高效地

构建和部署应用。无论身处哪个行业、规模如何，所有企业都需要周全地考虑各种活动、技术、团队和流程，因为这些要素综合起来才能实现 DevOps 文化。要想充分利用新技术，采用更加快速的方案，实现更为密切的合作， 企业必须切实遵循 DevOps 的原则和文化价值，并围绕这些价值来进行组织和规划。

这个实际上我在前面已经讲过了，即：

要实现微服务的技术架构和拆分，那么首先就要在业务组织架构上拆分。

那么业务组织架构拆分的重点，又是遵循康威定律，围绕价值交付。

比如上图可以看到，如果按软件生命周期的方式来划分团队，那么需求团队最终的交付结果本身是对最终用户没有价值的，类似的包括设计团队，开发团队。而只有按照迭代的思路，将大的产品功能拆分为独立的业务子功能。

每一个拆分后的业务功能都是用户能够感知和验证的功能点。

同时 将拆分后业务功能分配到不同的业务交付团队 ，那么这个时候重组和拆分后的业务功能团队都能够实现面向用户的最终价值交付团队。

DevOps 文化的推行不仅要靠工具和技术，也取决于员工是否愿意和信任用集成度和协作度更高的方案来开发和交付应用。要实施微服务和DevOps，首先就是要 构建DevOps 文化，并基于价值交付思路对业务团队进行拆分和重构。

步骤 2：借助高速单体式技术，为现有应用提速

这个步骤即我前面讲过的对传统的单体应用进行微服务拆分。而这个本身又包括两个关键内容。

• 其一是对单体应用中共性技术组件剥离
• 其二是单体应用进行微服务模块化拆分，包括组件识别和API接口识别

微服务模块的拆分方法 实际上在我们前面文章给出过。我当时谈的几个重点，即：

• 可以根据业务流程和阶段分析，阶段往往是微服务粒度划分点
• 对业务交互矩阵进行CRUD分析，确定某个细粒度业务功能的归属
• 对数据架构进行聚合分析，确定数据库究竟应该如何拆分

即通过上面的步骤，我们最终要拆分出来具体的微服务模块，每个微服务模块对应的数据库拆分，每个微服务模块包括的具体业务功能。

有了这些内容后，我们再进行业务流程交付分析，基本就可以识别和定义出具体的API接口服务。对应接口服务定义，需要遵循领域建模思路进行，尽量提供粗粒度的领域服务能力。

步骤 3：借助应用服务，加快开发速度

可复用性一直都是加速软件开发的关键所在；云原生应用也不例外。

云原生应用的可复用组件必须经过优化，并整合到底层云原生基础架构中，以便充分发挥复用优势。既然可以使用经过优化并整合到基于容器的底层基础架构中的现有应用，那为什么还要重建缓存服务、规则或工作流引擎、整合连接器、移动和 API 管理功能、数据虚拟化服务、消息代理呢？

注：这里强调的即是我前面谈到的传统单体里面的共性技术服务能力剥离和下沉。这个也是云原生解决方案里面的一个重点。只有技术服务组件剥离后，原有的单体应用才能够彻底的做到业务组件化，不再有原来私有的共性底层技术平台依赖。

如果再到ServerLess无服务器化阶段，你可以看到连重的开发框架都没有的，全部是基于事件和函数调用，来组合底层已有的技术服务能力。

云原生应用可能需要一种或多种此类服务，以帮助开发人员加快新应用的开发和上市。DevOps 和容器可加快云原生应用的交付和部署，而应用服务则可加快云原生应用的开发。

云原生应用开发人员可利用的应用服务，不仅能确保在基于容器的基础架构上顺利运行，也能充分利用各种平台功能，如 CI/CD 管道、滚动和蓝/绿部署、自动可扩展性、容错等。

步骤 4：欲善其事，必先择其利器

由于可根据特定的业务应用需求来选择语言或框架，而且这样的选择越来越多样，因此，云原生应用的构建方式也正变得越来越丰富。要应对因上述状况而不断增长的复杂性，您可以借助基于容器的应用平台，这类平台可以帮助您选择正确的框架、语言和架构组合来支持云原生开发。

要想实现云原生开发，还需要选用适当的工具来完成相应的任务。无论在实施云原生应用时采用的是 12 要素方案、基于域的设计、基于测试的设计和开发、MonolithFirst、快速单体式应用、迷你服务还是微服务，云原生平台都必须提供恰当的框架、语言和架构组合，以支持选定的开发需求。

注意，在前面我们也谈到过，要实现一个完整的DevOps也需要大量开源工具进行整合和集成。

如上图所示。我们可以通过禅道或JIRA等工具来实现敏捷研发管理，通过Git来管理我们的源代码。通过Jekins来实现持续集成和流水线设计。

在测试方面，可以通过sonar来实现静态代码检查，通过Junit来进行单元测试，通过Jmeter来实现单元测试和自动化测试等。而对于关键的容器集成，则通过kurbernetes来实现集群调度和容器资源编排。

而对于后续的日志监控，可以集成标准的ELK方案，也可以集成各种可视化监控工具和时序数据库来实现动态的心跳监控和数据分析。

即使对于一个完整的微服务治理，我们也可以看到有大量的开源工具可以选择，来实现我们常说的服务链监控，服务限流熔断，服务注册发现等关键功能。

步骤 5：构建可按需提供的自助式基础架构

通过自助式地按需置备基础架构，开发人员可以在需要时访问所需的基础架构。通过这种方式，可以有效消除未经授权的影子 IT。但是，只有当 IT 运维团队能够控制并了解不断变化且状况复杂的环境时，这种模式才有效。对于白皮书中这部分内容写的相当拗口。

简单来说就是我们需要通过构建一个完整的DevOps支撑平台来实现敏捷研发管理工具，底层容器云平台的完整集成，同时实现整个软件开发的持续集成和持续交付能力。

什么叫自助式服务？

自助式服务一个核心就是 尽可能的减少人为无效沟通和协同。

就是整个流程应该是类似流水线一样自动执行的，是事件驱动方式推着前进的，而不是需要人工去沟通协同，去问是否有新的工作任务产生。

在最早我谈敏捷研发，DevOps，容器云协同时候就谈到。比如我们自动化完成的编译构建，打包部署后，我们需要自动进行自动化测试，在自动化测试通过后，系统自动将待部署的Bug变更状态为待验证状态，并通知到测试人员。

再比如当某一个变更版本，在SIT环境进行完测试，测试人员对所有的Bug都验证关闭后，应该可以自动化的迁移版本到UAT环境等。

步骤 6：实现 IT 自动化，加速应用交付

避免手动执行 IT 任务，是加速交付云原生应用的重点，而实现 IT 或基础架构自动化就是其中的关键所在。从网络和基础架构置备，到应用部署和配置管理，自动化可以整合并应用于任何任务或组件。IT 管理和自动化工具会创建可重复的流程、规则和框架，以替代或减少会延迟上市的劳动密集人工介入。

注：红帽收购Ansible后，重点在推该工具实现自动化和持续集成交付。

步骤 7：实施持续交付和高级部署技术

敏捷开发方法经过不断演变，形成了“早发布，常发布”模式。DevOps 和持续交付方案通过密切联合开发人员、运维、质量保证和安全团队，扩展了这些方法的应用领域，从而改善了软件的交付流程。

因此，代码的变动可以快速可靠地推送至生产环境，为开发人员提供快速反馈。这种迭代式快速反馈循环借助 CI/CD 实现， 可将基础架构自动化扩展到端到端自动交付系统，从而涵盖应用交付的方方面面，包括自动化测试、漏洞扫描、安全合规性和法规检查。自动化交付管道旨在不影响运维能力的情况下提供更新，同时降低交付风险。

注：这块仍然是属于DevOps支撑平台提供的内容。

步骤 8：推动变革，采用模块化程度更高的架构

在基于微服务的软件编写架构方案中，应用被拆分成最小的组件，并彼此独立。

不同于将所有组件内置于同一架构中的传统单体式方案，微服务都是独立的组件，通过合作来完成相同的任务。此种软件开发方案强调高精度、轻量化，力求在多个应用中共享相似的流程。虽然微服务架构不要求使用特定的底层基础架构，但基于容器的平台可以打下最扎实的基础。

分析师建议对微服务采用 MonolithFirst 方案，即要先构建一个单体式应用，就算您想创建的是微服务架构。这么做的目的是：先充分理解您的应用所属的域，然后更好地识别其所含的有限上下文——这些上下文将作为转换成微服务的候选内容。这样做，有助于避免技术债务，比如还没有了解应用的所属域和有限上下文就构建一组微服务，由此产生的修复成本。

注：个人不建议该方式，实际上正是我前面提到的，即使是采用微服务架构，整体的业务架构规划，技术架构规划设计仍然必须统一以保证概念完整性。