云原生应用构建:基于OpenShift
上QQ阅读APP看书,第一时间看更新

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

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

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

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

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

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

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

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

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

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

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

随着物联网(IoT)、机器学习、人工智能(AI)、数据挖掘、图像识别、自动驾驶等新兴技术的兴起,应运而生的应用开发框架也越来越多,如图1-1所示。我们需要根据特定的业务应用需求来选择语言或框架,因此不同的云原生应用会采用不同的应用开发框架。这就要求容器PaaS平台能够支持多种应用开发框架。Red Hat OpenShift可以支撑多种应用开发框架,后面章节会详细介绍云原生Java(第3章)和Serverless(第10章)在OpenShift上的实现。此外,我们也会在第11章中介绍人工智能在容器云上的实践。为了方便读者理解云原生开发,我们在第2章会先介绍如何在传统Linux上构建应用包。

图1-1 应用开发框架

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

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

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

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

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