基于 DevOps 的微服务生态系统与工程实践(三)

往期回顾:

第一部分:基于 DevOps 的微服务生态系统与工程实践(一)

第二部分: 基于 DevOps 的微服务生态系统与工程实践(二)

本文来自于 GOPS 2017 深圳站的演讲《基于 DevOps 的微服务生态系统与工程实践》,DevOps时代公众号连续三篇文章详细解读DevOps与微服务的秘密。

作者简介:

王磊 华为 中央软件院首席软件工程技术专家 国内首批 DevOps Master 认证讲师,《DevOps Handbook》中文译者。 并著有国内首本微服务架构相关书籍《微服务架构与实践》一书。

前言

从2014年开始,当我接触微服务之后,我发现在微服务的演进过程中,开发和测试、运维需要相亲相爱,紧密合作,才能取得理想的效果。

本系列文章主要包括三部分内容:

第一部分:微服务与 DevOps; 第二部分:微服务生态系统; 第三部分:微服务架构的工程实践;

本文着重介绍第三部分:微服务架构的工程实践。

四、微服务架构的工程实践

最后是微服务架构的工程实践。这是 Netflix 从09到16年七年时间,把他的业务从数据中心迁到 AWS 之后的架构图。对于我们的系统而言,是不是意味着当我们把架构拆分成50个、100个之后,也能获取到这样收益呢?

这是很多组织和团队在做微服务的时候考虑的第一个问题。如果我们把架构拆成50个,100个,是否能获得同样的收益?答案是否定的。Netflix 首席云架构师说过,他们做了大量的关于流程工具和实践的演进。

4.1 开发实践

我们在过去的微服务演进过程中所遵循的优秀实践,对于开发而言,这里我只提三个实践:

1.首先对于每个服务而言,最基本、最简单的需要给每个服务建一个独立的代码仓库,目的是让这个服务能够被隔离,而不是打开之后发现有很多相关的代码。

2.第二点——自解释文档。因为在过去的很多案例里面,我发现可能会用 Word 来写文档,可能会用别的方式来写文档,但是这个文档会涉及很多设计的内容,在很多实践中并不太关心服务本身的流程跟设计,更关心的是我要知道这个服务是干什么,这个服务出问题了可以找谁协调。

作为新的开发人员,我能够花多长时间去运行起来这个服务,意味着这个服务的代码地址在哪里,CI在哪里,当我部署的时候,通过什么方式去完成类生产环境和测试环境的部署。

3.第三——易于本地运行。当我们做了服务拆分之后发现很多团队里面的服务,都不能独立在本地运行,怎么让开发人员快速交付,这里列了三个经常用的方法。

•第一个是用本地环境配置加 Mock 的方式,可以定义成自己的 MOCK,把我们关注的服务在本地环境里迅速搭建起来。

•第二个是使用 Docker-compose

•也可以用共享的环境,可以在云上部署一些依赖环境。

这是过去一个真实的案例,我们定义了ETL的服务,做的是把服务里面的数据同步给原有的系统,这种模式在微服务演进过程中非常常见,这个过程中对于数据传输而言,最重要的是油标,我要保证我的传输不会重复,同时数据不会丢失,所以我们把油标保存在亚马逊的 S3 上面。

但是本地开发的时候,开发效率降低,原因是你从本地访问 S3 会比较慢。为了解决这个问题,我们把S3做了一个 Mock,可以用任何 Mock 框架定义,这样本地运行的时候,就不用关心具体S3的操作,我只要关心钓到了就可以,因为它本身是第三方的业务,非常稳定。

4.2 测试实践

对于测试而言,一定要清楚测试策略的三角形。当我们去思考测试的时候,不是只有一种系统性的测试,而是由单元、集成、组件和端到端的测试。每种测试给我们带来的价值不一样,越往底层走,单元测试效率最高,但是没有办法从真正的用户角度考虑业务价值问题。

越往上走,很容易描述,比如说我希望用户能够输入用户密码,能够成功登录,但是它所带来的测试如果只是从上面做的话,成本非常高。因为我们需要或者用人工、或者自动化方式打开网页,反馈周期也比较慢,可能你在页面上做了很多测试,后来发现最后一个错误是由于开发人员在某一行代码里面的错误变量。

所以在过去的测试例子里,我更多讨论的是“集成测试”,通常是“契约测试”,什么意思?我在提供者和消费者之间提供契约,里面记录的是在交付过程中,我的请求是什么样,我的响应是什么样,是不是有一些原数据来描述请求和响应的过程。

有了这个契约之后,当我们的结构发现破坏,我的提供者满足不了当前所定义的契约,我其实不需要真正到生产环境上去破坏消费者,就能在测试环境里验证出当前的提供者已经破坏了契约,如果让他上线是非常危险的事情。

基于契约测试在业界有一个框架,叫「消费者驱动契约测试实践」,是把 BDD 和 TDD 无的模式引到架构层面,对于两个服务而言,如果我存在消费者、提供者,我的价值点一定是在消费者这里,我希望从消费者逻辑本身去驱动我的契约,有了这步之后,拿这个契约验证我的提供者,这种方式就简化了很多。

通过这种方式还有最大的优势在于,它把我们的两个在线的集成测试,比如我们过去做集成测试,最简单能想到的就是把所有的服务全部署上去,用自动化或者人工的方式发请求,让请求跟过程发生交互或者提供结果,这对服务的稳定性要求都非常高。

所以在过去是通过这种方式之后,你会发现我可以把原本的集成测试变成两个独立的线下的单元测试。左边关心的是消费者能不能驱动出这个契约,右边关心的是契约能不能被提供者所验证。

这是我们使用最多的框架叫 Pact,为什么我们选择这个,是因为对多语言支持比较好,同时这里有一个非常重要的点,我们可以把生成的契约全部收集起来,因为契约里描述了请求和响应的过程,可以进行重绘,很容易就实现了调用图。

4.3 部署实践

第三个是部署,当我的持续集成把包构建出来之后,把包存储到某个地方,这时候只需要关心我的部署流水线,从哪里获取包,部署到类生产和生产环境上。

最核心的挑战点在于部署流水线,提一个小的建议,对于部署流水线而言,现在的工具很多,但是最核心的是我们要很清楚的知道,我们的包是如何管理的,包的版本化、包的命名方式,比如过去做服务的时候,每个服务的命名方式都是很清楚的。

第二,对于部署而言,我们要尽最大程度,尤其是从事运维同事,一条命令里只需要三个参数:第一我的服务名字,第二我的版本号,第三是我的开发环境,这是在部署演进过程中所要考虑的核心问题,当然对于 deploy 之后采用什么工具和方式,是在团队内部可以协商的,现在开源的工具很多很多。

4.4 运维实践

最后是运维,运维里面包括三点,监控,告警和日志聚合。我只提几个核心的关键点,系统监控关心的是 CPU 内存和磁盘;应用监控关心的是应用本身,可能会有响应时间、健康检查。

第三部分是延伸的部分,我们是不是要考虑对应用本身建构它的业务场景,比如通过一些收集的方式,监控在运行过程中业务是否运行正常,而不仅仅是对可用性的检查。告警里面要有很清晰的通知方式,还要有告警升级的策略,对于告警升级一般会有 oneCall 工程师,Backup工程师和服务 owener。

第一步你要评估带来的影响性;

第二是组内发邮件,先让有经验的工程师帮你做评估;

第三才是 mitigate,你要花最快的时间把这个服务覆盖掉;

这个流程是对于线上服务去做运维的常见流程。

日志聚合。对于服务化之后,50个,100个,200个,这种服务你的日志怎么获取,需要一种独立的日志聚合机制,能够帮助我们收集很多服务的调用链,对日志做分析告警,常用的有ELK,可以很方便支持日志输出和收集。这三点是我认为在运维监控里可能是被大家平时忽略的点。

五、总结

最后推荐几本书,大部分是关于持续交付和 DevOps 的书籍,不管我们如何清晰定义概念的划分,但是实践过程中三者是密不可分的。

文章来源:DevOps时代社区

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏架构师之路

好架构是进化来的,不是设计来的(58架构演进)

好的架构化是进化而来的,不是设计出来的 ----58沈剑 核心内容:58同城流量从小到大过程中,架构是如何演进的?遇到了哪些问题?以...

37013
来自专栏智能计算时代

微服务与SOA架构(1)

image.png 基于服务架构的世界 微服务和SOA都被认为是基于服务的架构,这意味着这两种架构模式都非常强调将“服务”作为其架构中的首要组件,用于实现各种功...

2204
来自专栏云计算D1net

多云管理工具:组织可能需要的6个功能

管理人员需要多云管理工具来确保资源安全,并符合适用的合规标准。他们还需要这些工具来帮助充分利用每个云平台的功能,同时最大限度地降低成本。

1384
来自专栏智能计算时代

2017年终奉献:微服务最佳实践

关键需求 最大限度地提高团队的自主性:创建一个团队可以完成更多工作而不必与其他团队协调的环境。 优化开发速度:硬件便宜,人不是。 使团队能够轻松快捷地构建强大的...

2935
来自专栏领域驱动设计DDD实战进阶

DDD实战进阶第一波(二):开发一般业务的大健康行业直销系统(搭建支持DDD的轻量级框架一)

本系列文章 DDD实战进阶第一波(一):开发一般业务的大健康行业直销系统(概述) DDD实战进阶第一波(二):开发一般业务的大健康行业直销系统(搭建支持DDD的...

3475
来自专栏北京马哥教育

大数据怎样帮助运维工程师实现无死角监控?

今天一大早就看到了一篇文章,叫【大数据对于运维的意义】。该文章基本上是从三个层面阐述的: 工程数据,譬如工单数量,SLA可用性,基础资源,故障率,报警统计 业务...

35411
来自专栏IT大咖说

经历了研发困局、运维之痛,同程微服务从1到1w的旅程

内容来源:2017 年 9 月 9 日,前同程艺龙架构师谢康在“ArchData技术大会上海站”进行《同程微服务从1到1w的旅程》演讲分享。IT 大咖说(微信i...

863
来自专栏DevOps时代的专栏

探索持续部署的过程 | 译文

解释持续部署(CDP)很容易。实施它非常困难,因为其中的挑战往往是隐蔽的和不可预期的。根据您的流程、体系结构和代码的成熟度,您可能会发现真正的问题不在于持续部署...

642
来自专栏DevOps时代的专栏

华为专家 | 轻量化微服务测试实践

前言 在我过去工作的这十年间,IT行业经历了很多的变迁,从单体架构到微服务架构,从传统组织到敏捷组织,我正好都有不同的体验,现在我在华为任软件架构师,华为有各种...

52610
来自专栏Rainbond开源「容器云平台」

干货下载:谷歌、亚马逊等十大公司微服务案例精选

1484

扫码关注云+社区