微服务的团队应对之道|TW洞见

这两年,微服务架构火了。在国内,从消费级互联网应用,到企业级应用;从金融领域,到电信领域;从新开发系统到已经开发了十几二十年的遗留系统;一夜之间,好像所有的团队都在谈微服务。

然而,我们为什么采用微服务呢?

“让我们的系统尽可能快地响应变化“ - Rebecca Parson

是的,让我们的系统尽可能快地去响应变化。其实几十年来我们一直在尝试解决这个问题。如果一定要在前面加个限制的话,那就是低成本的快速响应变化。上世纪九十年代Kent Beck提出要拥抱变化,在同期出现了诸多轻量级开发方法(诸如 XP、Scrum);2001年敏捷宣言诞生,之后又出现了精益、看板等新的管理方式。如果说,这些是为了尽快的响应变化,在软件开发流程和实践方面提出的解决方案,那么微服务架构就是在软件技术和架构层面提出的应对之道。

微服务是如何做到的?

微服务是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。 — James Lewis and Martin Fowler

这是James和Martin2014年在《微服务》一文中提到的对于“微服务”的定义。相对于单体架构和SOA,它的主要特点是组件化、松耦合、自治、去中心化,体现在以下几个方面:

  • 一组小的服务

服务粒度要小,而每个服务是针对一个单一职责的业务能力的封装,专注做好一件事情。

  • 独立部署运行和扩展

每个服务能够独立被部署并运行在一个进程内。这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏,使得快速交付和应对变化成为可能。

  • 独立开发和演化

技术选型灵活,不受遗留系统技术约束。合适的业务问题选择合适的技术可以独立演化。服务与服务之间采取与语言无关的API进行集成。相对于单体架构,微服务架构是更面向业务创新的一种架构模式。

  • 独立团队和自治

团队对服务的整个生命周期负责,工作在独立的上下文中,自己决策自己治理,而不需要统一的指挥中心。团队和团队之间通过松散的社区部落进行衔接。

我们可以看到整个微服务的思想就如我们现在面对信息爆炸、知识爆炸是一样的:通过解耦我们所做的事情,分而治之以减少不必要的损耗,使得整个复杂的系统和组织能够快速的应对变化。

My First Law of Distributed Object Design: Don’t distribute your objects (From P of EAA). - Martin Fowler

然而谈到微服务,我们不能忽视的一点是:微服务仍然是典型的分布式系统,它必然有分布式系统固有的问题:诸如怎么部署,出错怎么办,怎么保证数据的最后一致性;与此同时,还有服务要多微?业务变化后服务如何调整?服务规模化后怎么办?如何避免一个服务改动导致的多个级联服务的失败?如何进行测试等等问题。

“微服务不是免费的午餐”。从实战中我们清楚地认识到选择任何架构都有利有弊,服务化也是一样。企业从微服务架构获益的同时,必然要面对切换到由众多服务组成的分布式系统后所带来的挑战。我们认为只有提升团队应对这些挑战的成熟度,才能真正使企业从这种微服务架构中获益。

那么对于即将和已经开始实施微服务的团队,应该如何应对呢?结合我们项目的经验,我认为应从DevOps、服务构建、团队和文化四点入手:

  • 首先需要考虑构建DevOps能力,这是保证微服务架构在持续交付和应对复杂运维问题的动力之源;
  • 其次保持服务持续演进,使之能够快速、低成本地被拆分和合并,以快速响应业务的变化;
  • 同时要保持团队和架构对齐。微服务貌似是技术层面的变革,但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另一大支柱。
  • 最后,打造持续改进的自组织文化是实施微服务的关键基石。只有持续改进,持续学习和反馈,持续打造这样一个文化氛围和团队,微服务架构才能持续发展下去,保持新鲜的生命力,进而实现我们的初衷。

在本文中会针对第一点,并以我们项目微服务的发展历程为例介绍我们遇到的各种坑和采取的相关措施,希望能够给正在准备实施和已经实施微服务的团队一些借鉴。

背景

我们于2012年在系统集成需求的驱动下走上了服务化之路,通过将重复的业务能力封装在几个服务之间完成了系统集成,并成功上线。最初只有8个服务支持我们的业务系统,服务与服务之间采取基于HTTP的RESTful API的方式进行通信,通过自动化脚本将应用部署到生产环境。

在随后的2年中我们的业务快速发展,增加到了60多个站点和服务。服务的上线周期也越来越短,从两年到两周。而这样的一套生产环境是由客户的2名运维人员手工维护的(包括基础设施构建),每次发布都会存在大量的人工干预,比如对部署结构和系统权限的修改等,给我们的整个生产部署和运维带来了较大的问题:

  • 大量的人工干预,频频出错。

手工方式始终是易错和低效的,而且会导致各种难以重现的环境问题(就如雪花服务器),这使得一些复杂点的运维工作,包括技术平台的整体升级、灾备系统搭建等很难开展,往往要提前半年甚至一年来进行筹备。当我们服务规模化和发布周期缩短之后,它带来的伤害又进一步明显起来。为了减小这种伤害,业务部门不得不降低发布频率,从两周延迟到一个月,因此也影响到了对最终用户的响应速度,并不得不采取Hotfix的方式来修正发布速度的问题,实际上又增加了问题的复杂度。

  • 缺乏有效的监控和日志管理,产品环境定位困难。

没有监控,无法及时知晓服务的运行状态。很多问题直到最终用户才能发现,问题反馈周期很长。同时,运维人员不懂开发人员的服务设计和调用流程,开发人员不懂产品环境的配置结构。当产品环境出错之后,往往要花费数小时才能定位到问题根源。

另外,负载均衡和单点服务降级无法真正开展,当一个服务出现问题时,需要关掉其所在的服务器。产品环境资源利用率低,运维成本居高不下。

2015年初,当我们遇到了Powershell的bug和服务不能正常启动的貌似随机问题时,就如遇到了那根压倒骆驼的最后一根稻草,客户对我们明确的提出“不要再添加任何一个服务了”。

残酷的事实再一次向我们证明,在这样一个复杂系统下,传统的手工运维方式必然要被淘汰,微服务的实施有一定的先决条件:基础的运维能力(如监控、快速配置、快速部署)需提前构建,否则就会陷入像我们一般如此被动的局面。而我们也看到,当服务规模化后需要更多自动化和标准化的手段来提升效能和降低成本。

……

阅读下半部分内容&文中蓝色字体对应链接请点击【阅读原文】

原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2016-07-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏腾讯大数据的专栏

App 数据分析到底要分析什么

DAU、MAU、留存率、频率、时长.....到底产品经理要分析什么数据?笔者结合海外移动端产品的数据分析实践与MTA服务的客户案例,带你从产品初创到成熟不同阶段...

1.2K1
来自专栏云计算D1net

专家支招:确保云计算安全的12种招式

1、确认现有的基础控制 基础控制是企业安全理念的核心。它们包含了将近60个保护您企业最重要资产的安全控制。它们专注在确保云技术对您业务的应用,以及您的操作是符合...

3344
来自专栏about云

该如何建设公有云私有云,需要考虑哪些问题,该选择什么技术?

问题导读: 1.云计算能够解决什么问题? 2.公有云面临哪些问题? 3.要建设云,你认为需要解决什么问题? 4.为什么选择openstack,建设公有云? 最...

5647
来自专栏SDNLAB

裸机云服务是云计算的下一个风口

云计算服务,尤其是基础设施即服务(IaaS)已经非常成熟,在业界得到了广泛的应用。但在某些情况下,用户需要更多的控制权、更多的硬件访问权、更高的性能以及选择自己...

4176
来自专栏大葡萄元元

APP测试背后的数据运营(运营篇)

最早接触测试是在某Android应用市场,利用测试机进行功能的测试以及合作广告的审核以及版权、是否能够正常运行以及产品的实际应用能力等一系列的人工测试,相对于白...

3772
来自专栏云计算D1net

PaaS的未来和应用价值

本文介绍了一位专家眼中PaaS的未来、当前应用以及其相关安全性方面的一些注意事项。由于不同版本的PaaS都有着它们各自的一片天,一些IT专业人士都在思考这一模式...

53313
来自专栏云计算D1net

CommVault为亚马逊云服务提供自动化数据保护

CommVault 近日宣布,公司已为亚马逊云服务(Amazon Web Service)增添了数据管理和保护支持,其中包括云端报告功能以及自助虚拟机配置、恢复...

3588
来自专栏云计算

移动开发即服务,腾讯云移动开发平台打造开发新模式

互联网“下半场”,移动App开发对于质量、效率的要求更加苛刻。传统移动开发的模式是移动开发者手动集成所需的各种移动服务,和后台服务紧耦合去打造精品移动应用。在传...

19.8K42
来自专栏SDNLAB

混合云的未来

回顾过去几年,混合云在IT界异军突起。据许多行业分析师的观点,混合云意味着将组织软件驱动的私有云与公共云的性能、业务流程、自动化和计费功能相结合,以实现在公有云...

3825
来自专栏Forrest随想录

谈谈架构标准化的问题(跟运维有关系?)

接上篇《运维架构是全站技术架构中不可分割的一部分》,文中提到一个问题,运维架构和技术架构的脱节这个问题到底出在哪了?到底谁应该承担这个责任?

1572

扫码关注云+社区

领取腾讯云代金券