Fork me on GitHub

什么是微服务 (microservices) 架构

微服务架构是一种设计软体系统的方式与风格。有别于原有的单体式系统,它进一步的将所有软体元件从运行在单一系统的框架,改变成为分散式的服务结构,进一步地去解决单体式系统的系统痛点。常见的单体式架构有以下的困扰 :

       1. 技术框架僵化
          受限于大一统的系统框架下,让各组件的实现方式必须单一化,无法去采用最适用的语言或者是框架。

       2. 牵一发而动全身的修改
          单体式系统的任何变更,都将涉及整个系统的更新与变动。大型系统的更新与变动,不仅是在编译准备或者是测试,都会随着系统变大而日益痛苦。

       3. 无效率扩容
          单体式系统含括了系统所有功能项目,有些元件可能是高耗CPU,有些则是高耗I/O;有些工作比较繁重,有些则比较轻松。但扩容需求产生时,由于单体式系统的不可切分,通常只能面对全系统的扩容,而无法以有效且针对性的进行效能增加。

       微服务在上述的背景下被提出,并且试着解决这些困扰。本篇文章将以Martin Fowler的专栏内容为参考,简单扼要地探索微服务的样貌。

       从Martin fowler的专栏[1]里可以看到以下简短的描述:

      the microservice architectural style [2] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

     简单地说就是微服务架构为一群有各自特定目标且独立运行的服务元件所组成的系统。各元件有独立的资料存储空间与事务逻辑,而各元件之间利用标准而轻量的通讯协定进行系统层级的协作,因此各服务均能被独立的布署与替换。

     看完上述扼要的定义后,再从Martin Fowler专栏内所提及的微服务特征来进一步了解微服务的概念,并且了解在建构微服务的系统时,应该考量的要素。系统的设计随着需求与发展,往往会有相应的取舍,能够符合所有特征自然是好,但若无法符合,至少可以知道改善的方向或者是取舍了些什么。

       1. Componentization via Services
           所谓的元件是指可被独立升级与替换的软体元件。因此在设计系统时,我们将有相同业务目标的功能聚集,并且独立服务化。各服务因此可以被单独地更换或者是升级,而不会进一步影响其它服务或者是系统的正常运作。以上的设计奠基于完善地介面设计与定义,因此在介面下的更新,并不会对系统或者是其它的元件造成太大的影响。
       2. Organized around Business Capabilities
           常见的组织分工往往会按人员技能不同而进行水平切割。比方说,有专业的UI/UX团队、专业的前端团队与专业的后端团队等,这种分工模式往往会造成较高的沟通成本。基于康威定律,我们也可以进一步观察到系统设计偏向水平切割,而难以采用微服务的设计概念。一个微服务设计架构下的团队,可以明显看见团队内的技术完整性,也就是垂直分工的协作模式。各服务元件围绕着本身的业务逻辑,并且由有完整技术链的小型团队各自负责所属服务元件的开发。小团队的作战模式,不仅降低了沟通成本也加深了团队成员对于服务元件业务逻辑的专业度。说到此,肯定有人会对于微服务的团队成员数目感到疑惑,到底一个以微服务作为设计原则的团队有多大,这个答案其实很难有个明确的数字,因为这也牵涉到组织人力资源的配置和服务元件的颗粒度大小。举个例子来说,Amazon提出所谓的「两块pizza」的概念,也就是说一个团队大小刚好就是两块pizza能够喂饱的大小。而以我自身的经验来看,大致上是两周可以妥善完成一个完整功能集的人数。
       3. Products not Projects
          常见资讯系统开发的分工结构为研发工程师负责系统开发,开发完毕后,开发团队写下完善的指导手册,并且交付维运单位进行日后维护,然后研发团队分派到新的研发专案上。这样的分工结构,很难有效解决快速变更的开发需求。另外,在沟通成本以及责任厘清上也都会产生不效率的情况。因此在微服务​​设计架构思维上,强调将相关的服务元件开发当作产品开发而非专案开发,也就是说,由专责的开发团队负责该元件的一切开发与维运责任直到产品日落为止。
       4. Smart endpoints around dumb pipes
           微服务架构下,更强调服务元件本身的内聚力。也就是说,服务元件应该更妥善地包裹负责的业务逻辑,然后进一步提供简单的接口让外部的其它服务取用,其它的服务只管知道如何从接口获得它要的资讯以及自身的业务逻辑要如何善用该资讯。完善封装的端口需要搭配的便是有效且简单的通讯机制,通讯机制本身不应该载负业务逻辑且应该采用更轻量且中性的通讯模式,比方说RESTful或者是Message Queue。
       5. Decentralized Governance
           有别于单体式系统,微服务架构允许服务去采用各自最适的技术方案解决服务内的业务功能需求,无须捆绑在单一技术堆叠之下而无法动弹。这是一个让系统设计得到可以进行充份选择的权利,松绑了原先的不自由,但这并不代表研发团队非得因为这样而拥抱多样化的技术堆叠,因为这涉及了人员技术的熟稔程度与日后维护的成本。另外,这样的概念能够被落实也有赖于前述第三点所提及的特点,因为团队对自身的服务元件有妥善负责的义务,因此可以让元件在技术选择上,得到一定的弹性与效率。
       6. Decentralized Data Management
           在单体式系统下,设计偏向于单一资料库系统的建置,然而这往往会导致设计上的一些困扰,比方说一样物品的属性,从不同的角度去观察往往有不同的意涵与表示的样貌,然而在单体式系统资料库上要显示这样不同的观点其实并不容易。沿着各自服务边界所设计的微服务有明确的功能范畴,搭配上独立的资料库,便可以轻松地以各自业务角度去解释与存储资料。然而这样的好处其实也不是完全无成本,分散式的系统所要面对的就是所谓的资料「最终一致性」的取舍。由于服务资料各自存储与管理,必然会产生同质不同义资料之间的同步迟延问题,这问题将有赖于各服务对于资料过期的处理方式与准则,让资料管理去中心化与同步迟延两者之间取得平衡。
      7. Infrastructure Automation
           这项特性其实就是目前最为人所乐道的运维技术风格──CI/CD。随着目前公有云服务商提供越来越多高弹性的运维环境,将枯燥而重覆性高的运维工作自动化,可以说是一个重要的趋势。但在自动化思维下,所必须要强调的一个前题则是服务元件的测试周全性。在进行运维布署自动化的同时,针对测试的自动化执行与监测也相对重要。
      8. Design for failure
           微服务架构设计使得软体系统内的沟通线更为复杂,使得服务在设计当下需要更积极地去考虑服务请求的失败和相应的处理,以避免服务停摆、崩溃或者是资料错误。除此之外,对于各服务的监测与容错测试也应该更为积极,让错误的讯息能即早被发现并且处理,而运维系统也应该提供更妥善的自动复原的功能,来进一步加强系统的稳定性。
      9. Evolutionary Design
           由于系统需求的变化、功能演进与快速更迭的需求下,服务的拆分与合并在微服务的概念下,更容易被实现,而微服务的开发者也更能拥抱这种循序渐进地改变方式,让系统的需求变更,能受到妥善的控制,而不使整体系统产生过大的冲击。至于拆分的准则,可以从服务功能是否能被独立替换或者是更新,作为其边界的要件;抑或者是按照功能本身的业务关联性进行拆解。如果遇到服务更新,屡屡会产生同时变动的情况下时,也可以进行合并,让各自服务的内聚力有效地提升。俗话说的好,软体系统唯一不变的就是它的易变性,渐进且逐步详细的设计与实作方式,才能更有效地提高系统的完整性。

      微服务的发展既是系统设计上的需要,也是相关技术与流程改善下所催生出的结果。讲到这边,难免又会讨论到是否微服务就是软体的银色子弹。答案应该仍然是明确的──不是。微服务虽然针对固有的单体式设计缺点而来,进一步改善了原有的缺点,但微服务本身所引进的成本也是明显的,比方说,分散式系统的管理问题与开发资源问题等。相对于单体式系统的初期运维成本和门槛,微服务架构是明显高了许多。因此,在系统设计初期,并不建议马上从微服务架构起手,仍然得按照自身的需求,进行系统的设计并且在合适的时机,进行架构上的转换与改善,让业务发展与资讯系统可以相互配合,而此一合适时机则有赖于组织软体能力的成熟度、软体设计的模组化和真实需求的发展,才能找到答案。

    

1: https://martinfowler.com/articles/microservices.html
2: The term "m> icroservice" was discussed at a workshop of software architects near Venice in May, 2011 to describe what the participants saw as a common architectural style that many of them had been recently exploring. In May 2012, the same group decided on "microservices" as the most appropriate name. James presented some of these ideas as a case study in March 2012 at 33rd Degree in Krakow in Microservices - Java, the Unix Way as did Fred George about the same time. Adrian Cockcroft at Netflix, describing this approach as "fine grained SOA" was pioneering the style at web scale as were many of the others mentioned in this article - Joe

登录注册 才能回复。