微服务和DevOps和容器关系(12.28)

标签: 微服务架构 | 发表时间:2019-12-28 10:04 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi

前面自己写过很多微服务,DevOps,容器化PaaS平台方面的文章,今天再梳理下几者之间的关系问题。

首先看下微服务,我们把微服务里面的一些关键组件拆分出来,其中包括了注册中心,配置中心,网关,限流熔断,服务链监控,可以看到这些组件都是可以独立的关键组件。

其次我们看下DevOps平台,在我原来的介绍里面也可以看到,我们将DevOps平台做为一个大的支撑平台,但是拆分后可以看到里面包括了敏捷研发管理,持续集成,容器化PaaS,测试平台等几个关键内容。再扩展点可能还包括了技术服务平台,后期的运维管理平台,面向生态的运营服务平台等。

微服务和API网关的关系

微服务,首先是业务组件化,从数据库到应用的全垂直化拆分。微服务一般采用SpringCLoud框架来进行开发,建议仍然是前后端开发分离的方式进行分层开发,更好的体现中台+服务+前端的思路。

谈到微服务,先谈和API网关的关系。对于微服务架构一定会用到微服务注册和管理中心,但是不一定就必须采用微服务网关。那么在什么时候需要引入网关,个人理解包括:

1. 前端有pc端,app端多种呈现方式的时候,需要引入网关,网关本身还起到类似DMZ区隔离作用。
2. 跨厂商团队协同的时候,需要引入网关,方便对不同厂商协同接口进行统一关联。
3. 中台能力需要对外进行能力开放的时候,需要引入API网关,方便对服务进行统一安全,日志,流控管理。

网关的引入增强了服务在安全,日志,流控,监控等方面的能力。注意如果仅仅是服务代理,你可能通过简单的ngnix来实现即可,但是要实现上面的诸多能力就必须要引入网关。

在谈微服务和DevOps的时候,我们把DevOps的核心能力进行拆分,包括研发管理,持续集成和交付,容器化PaaS几个关键核心能力。然后再来分析相互之间的依赖关系。

在转型到微服务的时候,个人认为实施持续集成是必须的,比如你通过jekins和maven结合来实现持续集成和持续部署,这个能力必须要用,但是你开始可能并没有实现容器化PaaS,这个影响不大,因为持续集成和自动化构建后已经解决了大部分问题,并不一定必须启用容器和镜像。

同时对于持续交付也不是必须,先做到持续集成,然后再考虑进一步做到持续交付。

微服务和DevOps平台关系

同时在实施微服务和DevOps的时候,容器化PaaS一开始也不是必须的,没有容器化PaaS我们也可以去实现自动部署能力,但是会缺失类似资源动态调度和扩展方面的能力,缺少对资源统一管理方面的能力。同时对于各个环境之间的迁移,到生产环境的持续交付也不方面。

一个容器镜像里面不仅仅是包括了中间件容器和部署包,可能还包括了其他一些配置文件,我们预安装的一些组件,要看到容器镜像完全将这些打包为一个整体,如果没有容器镜像粒度,我们在进行环境迁移的时候会相当麻烦,而且很难确保整个过程不出现差错,出现不一致的情况。

那我们考虑什么时候必须引入容器化PaaS,具体如下

1. 整个微服务的团队和模块规模都很大到一定程度的时候,必须要引入
2. 对于环境迁移和持续交付有明确的要求的时候,特别是对于持续交付的高要求
3. 对整个部署架构有明确的资源动态调度和弹性扩展需求
4. 需要更好的对IaaS平台层资源池进行统一的管理和资源分配

简单来说就是规模一大,而且需要贯穿到最终的交付环境必须引入容器化PaaS平台。来实现自动化的部署,应用托管,动态的资源管理和调度,持续到生产环境的交付。

因此对于DevOps也是同样的道理,一开始你可以没有容器化,但是后续必须要容器化,而且容器化这块要必须松耦合,即可以对接当当前主流公有云的IaaS平台,或容器化PaaS平台。

简单总结下前面阐述的内容,即:

1. 微服务架构和实施不一定需要DevOps完整体系,但是至少需要持续集成
2. DevOps不一定必须包括容器化PaaS平台,但是必须提供自动化部署的能力
3. 微服务不一定必须要API网关,再需要增强服务管控治理能力和对外能力开放时候必须采用API网关。

 

相关 [微服务 devops 容器] 推荐:

微服务和DevOps和容器关系(12.28)

- - 人月神话的BLOG
前面自己写过很多微服务,DevOps,容器化PaaS平台方面的文章,今天再梳理下几者之间的关系问题. 首先看下微服务,我们把微服务里面的一些关键组件拆分出来,其中包括了注册中心,配置中心,网关,限流熔断,服务链监控,可以看到这些组件都是可以独立的关键组件. 其次我们看下DevOps平台,在我原来的介绍里面也可以看到,我们将DevOps平台做为一个大的支撑平台,但是拆分后可以看到里面包括了敏捷研发管理,持续集成,容器化PaaS,测试平台等几个关键内容.

DevOps 实战

- -
DevOps 的 3 个支柱. 第 1 步:寻找合适的试点项目. 第 3 步:快速建立初期成功. 第 4 步:快速展示和持续改进. 第一阶段:每次提交触发完整的流水线. 第二阶段:每次流水线触发自动化测试. 第三阶段:出了问题可以在第一时间修复. 第二步:定义指标并达成一致. 第三步:建立自动化执行和检查能力.

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

『DevOps 最佳实践』 — DevOps 实践

- -
Culture – 文化:公司各个角色一起担当业务变化,实现有效协作和沟通;. Automation – 自动化:在价值链中尽量除去手工步骤;. Lean – 精益:运用精益原则更频繁地交付价值;. Metrics – 度量:度量并使用数据来优化交付周期;. Sharing – 分享:分享成功和失败的经验来相互学习.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

『DevOps 最佳实践』 — DevOps 平台 - Ledge DevOps 知识平台

- -
DevOps 数字化转型框架. 企业为什么需要一站式综合研发平台. 越来越来多的组织开始搞敏捷和 DevOps 转型,打造了很多的 DevOps 基础设施,比如有管理需求的 Jira, 有持续集成的 Jenkins,有容器编排的 K8S 等等. 可是这纷繁复杂的 DevOps 工具链,同时也给企业带来新的困扰.

DevOps,你真的了解吗?

- - IT经理网
与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少. 根据CA的一项 调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作. DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后.

Kubernetes 会不会“杀死” DevOps?

- - InfoQ推荐
DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile). 传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求.

DevOps最佳实践(200711)

- - 人月神话的BLOG
今天准备谈下DevOps过程最佳实践以及DevOps支撑平台建设中的一些思考. 在前面文章里面我就已经谈到了传统企业IT架构转型或企业数字化建设需要解决两个方面问题. 其一:业务层面,重点是中台规划和建设. 其二:技术层面,重点是云原生解决方案,包括了微服务,DevOps和容器云. 当然,如果你是传统的软件开发框架技术,或者传统的基于虚拟机的PaaS平台也可以上DevOps实践,但是我们更加推荐的还是基于微服务和容器云技术来实践DevOps.

DevOps的“定义”:DevOps究竟要解决什么问题?

- - InfoQ - 促进软件开发领域知识与创新的传播
近些年来,DevOps 在我们身边出现的频率越来越高了. 各种大会上经常出现 DevOps 专场,行业内的公司纷纷在都招聘 DevOps 工程师,企业的 DevOps 转型看起来迫在眉睫,公司内部也要设计和开发 DevOps 平台……这么看来,DevOps 似乎无处不在. 可回过头来想想,关于 DevOps,很多问题我们真的想清楚了吗.