PaaS的全称为Platform-as-a-Service,含义为平台即服务。
在Docker出现以前,企业IT的建设更多是围绕IaaS进行的。IaaS的基础包括计算虚拟化、网络虚拟化、存储虚拟化,在此之上构建云管平台。
绝大数的企业级PaaS产品是以K8s为核心的,红帽的OpenShift3也是如此。OpenShift4更进一步使用CRI-O替换了Docker容器引擎,极大地简化了OpenShift集群的支持和配置。
OpenShift作为本地容器编排平台,既可以享受K8s的优势,同时又可以使用OpenShift商业支持的本地PaaS解决方案。
DevOps中的Dev指的是Development(开发),Ops指的是Operations(运维),DevOps就是打通开发运维的壁垒,实现开发运维一体化。
敏捷开发是开发领域里的概念,以敏捷开发阶段为基础,有如下阶段:
DevOps涵盖了整个开发和运维阶段。涵盖自动化软件开发和IT团队之间的流程,以便他们可以更快速、更可靠地构建、测试和发布软件。
传统的巨大单体应用程序在部署和运行时,需要单台服务器具有大量内存和其他资源。巨大的单体应用必须通过在多个服务器上复制整个应用程序来实现横向扩展,因此其扩展能力极差。此外,这些应用程序往往更复杂,各个功能组件紧耦合,使得维护和更新更加困难。在这种情况下,想单独升级应用的一个功能组件,就会有"牵一发而动全身"的困扰。
在微服务架构中,传统的巨大单体应用程序被拆分为小型模块化的服务,每项服务都围绕特定的业务领域构建,不同微服务可以用不同的编程语言编写,甚至可以使用完全不同的工具进行管理和部署。
与单体应用程序相比,微服务组织更好、更小、更松耦合,并且是独立开发、测试和部署的。由于微服务可以独立发布,因此修复错误或添加新功能所需的时间要短的多,并且可以有效地将更改部署到生产中。由于微服务很小且无状态,因此更容易扩展。
微服务通常具有以下特点:
微服务架构的特点,但实现方式不同:
在K8s出现和普及之前,实现微服务架构需要通过像Spring Cloud这种代码侵入的方式实现,也就是说,在应用的源代码中引用微服务架构的治理组件。
在K8s出现之后,可以将容器化应用之间的路由、安全等工作交由K8s实现,也就是说,应用开发人员再也不必在开发阶段考虑微服务之间的调用关系,只需关注应用代码的功能实现即可。
这种无代码侵入的微服务架构(如Istio)越来越受到业内和客户青睐,而本书也会着重介绍基于Istio实现微服务。
从技术角度而言,企业实施微服务大致有以下几个方面收益:
微服务遵循一些原则和最佳实践:
容器引擎使容器具备了较好的可操作性和可移植性,K8s使容器具备企业级使用的条件。而IT界企业级容器云平台——OpenShift又成为DevOps和微服务落地的新一代平台。
OpenShift以容器技术和K8s为基础,在此之上扩展提供了软件定义网络、软件定义存储、权限管理、企业级镜像仓库、统一入口路由、持续集成流程(S21/Jenkins)、统一管理控制台、监控日志等功能,形成覆盖整个软件生命周期的解决方案。
所以说,OpenShift本身提供开箱即用的PaaS功能,还可以帮助客户快速实现微服务和DevOps,并且提供对应的企业级服务支持。
云原生的重点是如何构建、部署和管理应用。
云原生应用的四大原则如下:
构建云原生应用的基础是:
第一步:
第二步:
第三步:
第四步:
第五步:
业务健壮性的提升,通常分为以下几步:
以OpenShift为核心逐步实现企业数字化转型的能力,分为四大部分: