云原生微服务容器DevOps概念扫盲!

Posted 2021-04-16 科技无忧订阅号

随着企业数据量持续增长、业务系统日趋复杂、市场竞争日趋激烈，用户需求需要得到越来越及时的响应，用户服务需要不间断地进行。但采用的传统的云计算服务模式，即按照传统模式开发业务系统然后部署到云上，会使得云计算按需定制、弹性伸缩等优势难以充分发挥。为解决以上问题，“云原生”就此诞生。

云原生是指专门为在云平台部署和运行而设计的应用及架构，符合云原生架构的应用程序应该是：

1.采用开源堆栈（Kubernetes+Docker）进行容器化

2.基于微服务架构提高灵活性和可维护性

3.借助DevOps支持持续迭代和运维自动化

4.以及利用云平台基础设施实现弹性伸缩、动态调度

更具体来说，云原生涉及一系列技术，典型技术包括以Docker和Kubernetes编排工具为主的容器技术、以Service Mesh为发展方向的微服务技术，以及以快速迭代、持续交付为目的的DevOps（开发运维一体化）技术。

关于容器技术

容器是指将应用程序及其环境一起打包作为交付物，该交付物可以随时构建、装载、运行。由于其它类型容器（如RKT）市场占比较低，容器一般指Docker。

容器编排工具是指让集群中的多个容器能够按计划、有组织运行的工具。Kubernetes作为CNCF孵化项目，相比Mesos和Swarm已经呈现出十分明显的优势。

传统虚拟机包含完整的操作系统，一旦开启即对硬件资源的一部分独占。容器引擎只是一个隔离的进程，对资源并不独占，因此是一种更轻量的虚拟化。这使得容器在文件体积、启动速度、占用资源和开启数量上都具有明显优势。

容器将依赖环境一起打包，因而屏蔽了开发、测试和运行环境的差异，再加上秒启、可多开的特性，使得微服务和DevOps均得以实现。所以可以说，容器技术是云原生的最佳载体，成为云原生的基石

关于微服务

采用化整为零的概念，将复杂的IT系统部署，通过功能化、原子化分解，形成一种松散耦合的组件，让其更容易升级和扩展。

每个应用组件将其自身功能以服务的形式展现出来，并按照预先定义的协议进行交互，各个服务组件之间是松耦合的。

某个应用组件的编程语言与技术选型不会影响主体应用，如某个服务组件可以用Java 开发，而另一个可以用.NET开发。

每个服务组件都可以享有自己的数据库，且该数据库仅供该服务组件自己使用，其他服务组件都不能读取或者修改。

每个服务组件都是可以自行部署和测试的，任何一个服务组件在测试、部署和运行的时候都不依赖其他服务组件。

任何一个服务组件的故障都应该是隔离的，单个服务组件的故障不应该拖垮整个应用，也不应该影响其他服务组件。

微服务是云原生的实现方式，不仅涉及技术架构，还涉及业务怎么划分以及组织如何管理，如不同步规划将无法发挥其价值。

关于DevOps

随着企业IT系统越来越复杂，功能迭代、局部升级、A/B Test甚至版本回滚成为常态，这都对开发、运维模式提出了新挑战，DevOps应运而生。

DevOps即开发运维一体化，是敏捷开发的继承和发展，目的是持续集成、持续交付，贯穿于开发到上线的始终。

DevOps因Docker的使用而更加简单，所以完整的DevOps体系中会包含Docker、Kubernetes等工具。

DevOps和微服务很多技术都是重合的，但两者的关注点并不同，微服务帮助我们以一种细颗粒度的方式开发、测试和发布服务，而DevOps提倡小规模和小批量的持续集成和持续部署，两者相辅相成的，共同解决问题；

DevOps进一步增强了云原生的敏捷特性，但其同样对企业内部的业务职责划分和组织架构调整提出了要求。

总结一下

容器+微服务+DevOps是实现云原生的最佳组合，但只有容器是一种比较明确的技术，而微服务和DevOps更像是一种方法论，仅仅有技术层面的配合是远远不够的，还需要有组织架构层面以及管理流程层面的共同配合才能发挥作用。

感谢朋友们转发，收藏，在看