2020-09-03 22:02 浏览量:832
虽然已经红了很久,但是“微服务架构”正变得越来越重要,也将继续火下去。
各个公司与技术人员都在分享微服务架构的相关知识与实践经验,但我们发现,目前网上的这些相关文章中,要么上来就是很有借鉴意义的干货,要么就是以高端的专业术语来讲述何为微服务架构。就是没有一个做到成熟地将技术传播出来,同时完美地照顾“初入微服务领域人员”,从 0 开始,采用通俗易懂的语言去讲解微服务架构的系列。
所以,我们邀请青柳云的苏槐与 InfoQ 一起共建微服务架构专题“Re:从 0 开始的微服务架构”,为还没有入门该领域的技术人员开路,也帮助微服务架构老手温故知新。
这是专题的第一篇文章,从最基础的地方入手,让我们重识微服务架构。
得益于 2013 年 Docker 的诞生,微服务概念及架构的推广和落地变得更加的可靠和方便。在 2016 年及之前,微服务架构的讨论更多的是活跃于互联网企业及社区。现如今,随着 Docker 和微服务架构组件与 Docker 等相关技术的逐步成熟,微服务架构已然步入传统企业及传统行业。
但是,程序员作为一个理性消费的群体,需要冷静地思考,避免挖个大坑把自己给埋了。所以,我们需要冷静地搞清楚:微服务(架构)是什么?它有什么优势劣势?我们为什么需要采用微服务架构?如何让老板接受这一新技术?如何落地?如何升级维护?等等……
我们在过去 7 年智慧城市的建设过程中,研发和交付了很多的大型项目,踩过很多的坑,趟过很多的雷,深受传统建设方法之苦,也深深被微服务架构带来的好处所感动,我们也将在微服务架构这条路的继续前行。在这里,将我们研发过程中的一些思考和心得分享给大家,供大家参考。
也许,在不久的将来,软件开发只需要组装,不再需要从头开发。
(点击放大图像)
形像一点来说,微服务架构就像搭积木,每个微服务都是一个零件,并使用这些零件组装出不同的形状。通俗来说,微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统,并利用简单的方法使多个小系统相互协作,组合成一个大系统。
如果学科派一点,微服务架构就是把因相同原因而变化的功能聚合到一起,而把因不同原因而变化的功能分离开,并利用轻量化机制(通常为 HTTP RESTful API)实现通信。
追本溯源,Martin Folwer 对微服务架构的定义是:
微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相协作(通常是基于 HTTP 协议的 RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,对具体的服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建 。(摘自王磊先生的《微服务架构与实践》)
对于我个人,我更喜欢一种延续性的解释,微服务架构≈ 模块化开发 + 分布式计算。不管微服务架构的定义怎么样,都是在描述一个核心思想:把大系统拆分成小型系统,把大事化小,以降低系统的复杂性,从而大幅降低系统建设、升级、运维的风险和成本。
顺带提一下,亚马逊创始人 Jeff Bezos 在 2002 年就说过:所有团队的模块都要以 Service Interface 的方式将数据和功能开放出来。不这样做的人会被炒鱿鱼。这才是思路超前的大牛。
需要注意的是“微服务”与“微服务架构”是有本质区别的。“微服务”强调的是服务的大小,它关注的是某一个点。而“微服务架构”则是一种架构思想,需要从整体上对软件系统进行通盘的考虑。
Chris Richardson 说:“微服务”是一个很糟糕的名字,它导致开发人员创建了许多粒度很小的服务,每个服务拥有一个单独的 REST 端点。不仅如此,这个名字还暗示了微服务在开发者心目中的重要位置。例如,人们会说“我们可以用微服务来解决这个问题”;我也看到了越来越多的“某某微服务框架”,而实际上,这些框架跟微服务架构不一定有太多联系,它们只是简单的 Web 框架。使用“微服务架构”这个名字会更恰当些。它是一种架构风格,它把一系列协作的服务组织成一个系统来支撑业务。
常见的微服务组件及概念
一般情况下,如果希望快速地体会微服务架构带来的好处,使用 Spring Cloud 提供的服务注册(Eureka)、服务发现(Ribbon)、服务网关(Zuul)三个组件即可以快速入门。其它组件则需要根据自身的业务选择性使用。
要谈优势,就一定要有对比,我们可以尝试着从两个维度来对比。
对于简单项目来说,单体架构 5 胜 8 败。(优势项:开发效率、上手难度、运维效率、硬件需求、项目成本;劣势项:系统设计(高内聚低耦合)、系统设计(扩展性)、需求变更响应速度、系统升级效率、知识积累、非功能需求、职责、成就感、风险)
对于复杂项目来说,单体架构 2 胜 11 败。(优势项:上手难度、运维效率;劣势项:硬件需求、项目成本、开发效率、系统设计(高内聚低耦合)、系统设计(扩展性)、需求变更响应速度、系统升级效率、知识积累、非功能需求、职责、成就感、风险;)
注:这里以使用方自行安装微服务为场景来比较。这里的共享库指的是像 Java 中的公共 jar 依赖。
看了上面的比较,微服务架构可以说是以压倒性的优势胜过单体架构和共享库,会让人产生一种错觉,微服务架构就是软件开发中的银弹。
但是,正如大家所了解的,软件研发是一个系统工程,它没有银弹,不能够一招鲜吃遍天。正如当年的 CMMI 和敏捷方法一样,敏捷虽好,但它不一定能适用于所有的场景,它对组织环境、团队氛围、沟通方式、技术能力这些都是有一些要求的,如果用不好,反而会带来一些负面影响。
那么,我们什么时候需要采用微服务呢?从我个人的经验来看,我认为有三种场景可以考虑使用微服务。
这里借一张图来说明:
(点击放大图像)
横轴是复杂度,纵轴是生产效率。从生产效率的角度来讲,在两条曲线的交叉点之前,单体架构是占优势的,过了交叉点之后,单体架构的生产效率将大幅度下降。
所以很多专家和同行朋友都说,我们可以在开始的时候先使用单体架构,当业务发展到一定程度的时候,再重构成微服务架构。对于这一点,我是持保留意见的,因为在实践中,架构改造的难度还是很大的,会有一些问题,例如:
√客户或业务部门是否给我们这样的时间窗口?
√这段时间的研发经费是否有出处?
√项目负责人或技术团队是否有主动的意愿进行架构升级?
√项目负责人或技术团队是否愿意为架构升级带来的不稳定风险负责?
我们常常听到的一句话是:暂时先这样,等我们没这么忙的时候,再来优化一下。但是,绝大多数情况下,这一天从来没有出现过。
再想想年初,我们的私有云平台经过 2 年多的发展,已经包含了容器服务平台(PaaS)、API 网关、监控平台、定时任务平台、数据库管理、用户权限管理等等十多个基础模块,也包含了一些为上层应用服务提供的日志服务、缓存服务、消息服务等等。并且,部署到了二十多个客户的生产环境里。可悲的是,我们支撑了很多的业务系统的微服务化,但平台本身任然是一个单体系统。
我们也深深地感受到了平台往前发展的阻力:
所以,春节过后,大家开了一个会,决定将平台微服务化。而带来的代价就是要说服老板给我们两个月时间来重构。
幸运的是,我们很快得到了老板的支持,并且重构工作比较顺利;不幸的是,那二十多个客户的生产环境的升级非常麻烦,每升级一个客户都得花上一周左右的时间,至今也才升级了一小部分。
所以,理想的情况下,我建议在项目初期的时候就从上面提到的三点做好评估,到底采用哪种架构形式是符合项目具体情况的。
当然,如果真的有朋友想将历史悠久的单体架构升级到微服务架构,我建议先从边缘逻辑开始,逐步逐步地将业务逻辑从单体系统里剥离出来。我没有这方面的经验,但可以想象,这将是一个非常长期和痛苦的过程。
作者介绍
苏槐,微信号 Sulaohuai,青柳云研发总监,现服务于神州数码青柳云团队,曾就职于 Oracle,新加坡电信等企业。擅长容器技术、微服务架构、敏捷开发及技术管理。
本文选自归极客邦科技 InfoQ