红帽资深解决方案架构师魏新宇：云原生应用构建之路

红帽资深解决方案架构师魏新宇：云原生应用构建之路

魏新宇 中生代技术

魏新宇，红帽资深解决方案架构师。在 IaaS、PaaS 方面有丰富的经验，致力于开源解决方案在企业中的推广和应用。从售前角度主导了红帽在金融、汽车行业的 PaaS 方面的多个项目。曾就职于华为、IBM、VMware，工作涉及领域包括硬件、AIX/Linux、虚拟化、PaaS、DevOps、微服务等。畅销书《OpenShift 在企业中的实践 PaaS DevOps 微服务》《云原生应用构建：基于 OpenShift》联合作者。获得红帽 RHCA Level 5 认证、RHCE 认证，以及 ITIL V3、Cobit5、TOGAF、C-STAR/TOGAF（鉴定级）相关认证。通过“大魏分享”（david-share）微信公众号，分享了很多项目实践经验。

1

云原生应用

1.1

什么是云原生应用

传统的软件开发流程是瀑布式的，开发周期比较长，并且如果有任何变更，都要重新走一遍开发流程。在商场如战场的今天，软件一个版本推迟发布可能到发布时这个版本在市场上就已经过时了；而竞争对手很可能由于在新软件发布上快了一步就抢占了客户和市场。

相比于传统应用，云原生应用非常注重上市速度。云原生应用是独立的、小规模松散耦合服务的集合，旨在充分利用云计算模型提高应用发布速度、应用灵活性和应用代码质量，并降低应用部署风险。虽然名字中包含“云原生”三个字，但云原生的重点并不是应用部署在何处，而是如何构建、部署和管理应用。通过表 1-1，我们可以比较清晰地看出云原生应用与传统应用之间的差别。

1.2

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

云原生应用所构建和运行的应用，旨在充分利用基于四大原则的云计算模型。

1. 基于服务的架构：基于服务的架构（如微服务）提倡构建松散耦合的模块化服务。采用基于服务的松散耦合设计，可帮助企业提高应用创建速度，降低复杂性。
2. 基于 API 的通信：即通过轻量级 API 来进行服务之间的相互调用。通过 API 驱动的方式，企业可以通过所提供的 API 在内部和外部创建新的业务功能，极大提升了业务的灵活性。此外，采用基于 API 的设计，在调用服务时可避免因直接链接、共享内存模型或直接读取数据存储而带来的风险。
3. 基于容器的基础架构：云原生应用依靠容器来构建跨技术环境的通用运行模型，并在不同的环境和基础架构（包括公有云、私有云和混合云）间实现真正的应用可移植性。此外，容器平台有助于实现云原生应用的弹性扩展。
4. 基于 DevOps 流程：采用云原生方案时，企业会使用敏捷的方法，依据持续交付和 DevOps 原则来开发应用。这些方法和原则要求开发、质量保证、安全、IT 运维团队以及交付过程中所涉及的其他团队以协作方式构建和交付应用。

在了解了云原生应用开发和部署的四大原则后，我们接下来介绍云原生应用的构建之路。

2

云原生应用构建之路的步骤

云原生应用的构建之路一共分为 6 个步骤。

步骤 1：发展 DevOps 文化和实践。

要完成云原生应用的构建之路，开发和 IT 运维团队必须进行多方面的变革，以便更加快速高效地构建和部署应用。各行各业的客户都需要周全地考虑各种活动、技术、团队和流程，因为这些要素综合起来才能实现 DevOps 文化。因此，要想充分利用新技术，采用更加快速的方案，实现更为密切的合作，企业必须切实遵循 DevOps 的原则和文化价值，并围绕这些价值来进行组织和规划。借助于 Red Hat 的 OpenShift，企业可以实现 DevOps 以及进一步的 DevSecOps 技术的落地。

步骤 2：借助轻量级应用服务器，为现有单体应用提速。

在开启云原生应用之旅时，企业不能只关注开发新的应用。很多传统应用都是确保企业顺利运营和不断创收的关键所在，不能简单地取而代之。企业需将这类应用与新的云原生应用整合到一起。但是，如何加快现有单体式应用的运行速度呢？

正确的方法是：将现有的单体式架构迁移到模块化程度更高且基于服务的架构中，并采用基于 API 的通信方式，从而实施快速单体式方案。在开始实施将单体式应用重构为微服务的艰巨任务前，企业应该先为他们的单体式架构奠定坚实的基础。虽然单体式应用的敏捷性欠佳，但其受到诟病的主要原因是自身的构建方式。运行快速的单体式应用可以实现微服务所能带来的诸多敏捷性优势，而且不会增加相关的复杂性和成本。

通过对快速单体式方案进行评估，可以确保应用在构建时遵循严苛的设计原则，以及正确定义域边界。这样，企业就能在需要时以更加循序渐进、风险更低的方式过渡至微服务架构。如能以这种方式实现快速单体式应用的转型，即可为优良的微服务架构打下扎实的基础。借助于 Red Hat OpenShift 和轻量级的应用服务器 Red Hat JBoss EAP，我们可以将传统单体应用迁移到容器中，为现有单体应用提速。随着 OpenShift 承载的单体应用越来越多，就会涉及传统 ESB 分布式的问题，即分布式集成。

步骤 3：借助 PaaS 平台和 DevOps 加快应用开发速度。

可复用性一直都是加速软件开发的关键所在，云原生应用也不例外。但是，云原生应用的可复用组件必须经过优化，并整合到容器 PaaS 平台和 DevOps 中。例如， CI/CD 开发流水线、PaaS 提供的滚动升级和蓝/绿部署、自动可扩展性、容错等，可以大幅提升云原生应用的开发速度。

步骤 4：选择合适的应用开发框架。

随着物联网（IoT）、机器学习、人工智能（AI）、数据挖掘、图像识别、自动驾驶等新兴技术的兴起，应运而生的应用开发框架也越来越多，如图 1-1 所示。我们需要根据特定的业务应用需求来选择语言或框架，因此不同的云原生应用会采用不同的应用开发框架。这就要求容器 PaaS 平台能够支持多种应用开发框架。Red Hat OpenShift 可以支撑多种应用开发框架。

步骤 5：借助可重复的流程、规则和框架，实现 IT 自动化，加速应用交付。

通过 IT 自动化流程、避免手动执行 IT 任务，是加速交付云原生应用的重点。IT 自动化管理工具会创建可重复的流程、规则和框架，以替代或减少会延迟上市的劳动密集型人工。这些工具可以进一步延伸到具体的技术（如容器）、方法（如 DevOps），再到更广泛的领域（如云计算、安全性、测试、监控和警报）。因此，自动化是 IT 优化和数字化转型的关键，可以缩短实现价值所需的总时长。

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

在微服务开发架构中，应用被拆分成最小的组件，并彼此独立。此种软件开发方案强调高精度、轻量化，力求在多个应用中共享相似的流程。虽然微服务架构不要求使用特定的底层基础架构，但基于容器的平台更易于微服务的落地。

通过微服务架构，企业可以在一天内多次执行生产部署。从架构的角度来看，微服务需将每一个服务拆分成各自的部署单元。随后，用户可单独管理和部署每个微服务，并且可能由不同的团队来负责各个微服务的生命周期。但是，实施微服务架构需要一定的投资和技能，企业在引入微服务时，可以采用 Monolith First 方案，即先构建一个单体式应用。这样做的目的是：先充分理解你的应用所属的域，然后更好地识别其所包含的有限上下文，这些上下文将作为转换成微服务的候选内容。这有助于避免技术债务，比如因不了解应用的所属域和有限上下文就构建一组微服务而产生的修复成本。能够支持不同的框架、语言和云原生应用开发方案的企业级 PaaS 平台（如 OpenShift），是云原生应用成功的关键。除此之外，在使用微服务后，我们还应考虑云原生应用的安全，如认证授权、单点登录、流量控制等。随着微服务的普及、业务系统复杂性的增加，我们还需要考虑 API 治理和业务系统分布式集成。