目录
- 引言
- 微服务的核心业务与技术特征
- 第一,围绕业务能力构建(Organized around Business Capabilities)
- 第二,分散治理(Decentralized Governance)
- 第三,通过服务来实现独立自治的组件(Componentization via Services)
- 第四,产品化思维(Products not Projects)
- 第五,数据去中心化(Decentralized Data Management)
- 第六,轻量级通讯机制(Smart Endpoints and Dumb Pipes)
- 第七,容错性设计(Design for Failure)
- 第八,演进式设计(Evolutionary Design)
- 第九,基础设施自动化(Infrastructure Automation)
- 总结
- 附
引言
微服务这个名词很早就出现了,Peter Rodgers 博士在 2005 年的云计算博览会(Web Services Edge 2005)上提出了 “Micro-Web-Service”,指的是一种专注于单一职责的、与语言无关的、细粒度的 Web 服务(Granular Web Services)。而这一阶段的微服务,是作为 SOA (Service-Oriented Architecture)的一种轻量化的补救方案而被提出来的。
2012 年,在“33rd Degree Conference”大会上,Thoughtworks 首席咨询师 James Lewis 做了题为《Microservices - Java, the Unix Way》的主题演讲。其中,他提到了单一服务职责、康威定律、自动扩展、领域驱动设计等原则,号召大家应该重拾 Unix 的设计哲学(As Well Behaved Unix Services)。
微服务真正崛起是在 2014 年,Martin Fowler 和 James Lewis 的文章“Microservices: a definition of this new architectural term”中,第一次真正丰富的、广为人知的和可操作的阐述了微服务指南。可以说,这篇文章是微服务的真正起源。文章定义了现代微服务的概念:微服务是一种通过多个小型服务的组合,来构建单个应用的架构风格,这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程之中。服务会采取轻量级的通讯机制和自动化的部署机制,来实现通讯与运维。
微服务的核心业务与技术特征
第一,围绕业务能力构建(Organized around Business Capabilities)
围绕业务能力构建,即康威定律,有怎样的结构、规模和能力的团队,就会产生出对应结构、规模、能力的产品。
如果本应该归属同一个产品内的功能,被划分在了不同的团队当中,那就必然会产生大量的跨团队沟通协作,而跨越团队边界,无论是在管理、沟通,还是在工作安排上,都会产生更高的成本。高效的团队,自然会针对这个情况进行改进,而当团队和产品磨合调节稳定了之后,就会拥有一致的结构。
(这对架构设计要求很高呀!)
第二,分散治理(Decentralized Governance)
微服务对应的开发团队,有着直接对服务运行质量负责的责任,也应该有着不受外界干预,掌控服务各个方面的权力,可以选择与其他服务异构的技术来实现自己的服务。
微服务更加强调的是,在确实有必要进行技术异构的时候,一个开发团队应该能有选择“不统一”的权利。比如说,我们不应该强迫用 Node.js 去开发报表页面;要做人工智能计算的时候,也可以选择用 Python,等等。
第三,通过服务来实现独立自治的组件(Componentization via Services)
这里强调要通过“服务”(Service)而不是“类库”(Library)来构建组件,是因为类库是在编译期静态链接到程序中的,会通过本地调用来提供功能,而服务是进程外组件,它是通过远程调用来提供功能的。尽管远程服务有更高昂的调用成本,但这是为组件带来隔离与自治能力的必要代价。
第四,产品化思维(Products not Projects)
产品化思维的意思就是,我们要避免把软件研发看作是要去完成某种功能,而要把它当做是一种持续改进、提升的过程。
开发团队应该为软件产品的整个生命周期负责。开发者不仅应该知道软件是如何开发的,还应该知道它会如何运作、用户如何反馈,乃至售后支持工作是怎样进行的。这里服务的用户,不一定是最终用户,也可能是消费这个服务的另外一个服务。
以前在单体的架构模式下,程序的规模决定了我们无法让全部的开发人员,都关注到一个完整的产品,在组织中会有开发、运维、支持等细致分工的成员,他们只关注于自己的一块工作。但在微服务下,我们可以让团队中的每一位成员,都具有产品化思维。因为在“2 Pizza Teams”的团队规模下,每一个人都了解全过程是完全有可能实现的。
(微服务时代的全栈工程师)
第五,数据去中心化(Decentralized Data Management)
微服务这种架构模式也明确地提倡,数据应该按领域来分散管理、更新、维护和存储。
在单体服务中,通常一个系统的各个功能模块会使用同一个数据库,虽然这种中心化的存储确实天生就更容易避免一致性的问题,但是,同一个数据实体在不同服务的视角里,它的抽象形态往往也是不同的。
另外,尽管在分布式中,我们要想处理好一致性的问题也很困难,很多时候都没法使用传统的事务处理来保证不出现一致性问题。但是两害相权取其轻,一致性问题这些必要的代价是值得付出的。
第六,轻量级通讯机制(Smart Endpoints and Dumb Pipes)
这个弱管道(Dumb Pipes)机制,是在直接反对 ESB、BPM 和 SOAP 等复杂的通讯机制。ESB 可以处理消息的编码加工、业务规则转换等;BPM 可以集中编排企业的业务服务;SOAP 有几十个 WS-* 协议族在处理事务、一致性、认证授权等一系列工作。这些构筑在通讯管道上的功能,也许在某个系统中的确有一部分服务是需要的,但对于另外更多的服务来说是强加进来的负担。
如果服务需要上面的某一种功能或能力,那就应该在服务自己的 Endpoint(端点)上解决,而不是在通讯管道上一揽子处理。微服务提倡的是类似于经典 Unix 过滤器那样,简单直接的通讯方式。比如说,RESTful 风格的通讯,在微服务中就是比较适合的。
第七,容错性设计(Design for Failure)
容错性设计,是指软件架构不再虚幻地追求服务永远稳定,而是接受服务总会出错的现实。
这个技术特征要求,在微服务的设计中,有自动的机制能够对其依赖的服务进行快速故障检测,在持续出错的时候进行隔离,在服务恢复的时候重新联通。所以“断路器”这类设施,对实际生产环境的微服务来说,并不是可选的外围组件,而是一个必须的支撑点。如果没有容错性的设计,系统很容易就会因为一两个服务的崩溃带来的雪崩效应而被淹没。
可靠系统完全可以由会出错的服务来组成,这是微服务最大的价值所在。
第八,演进式设计(Evolutionary Design)
容错性设计承认服务会出错,而演进式设计则是承认服务会被报废淘汰。一个良好设计的服务,应该是能够报废的,而不是期望得到长久的发展。
如果一个系统中出现不可更改、无可替代的服务,这并不能说明这个服务有多么重要,反而是系统设计上脆弱的表现。微服务带来的独立、自治,也是在反对这种脆弱性。
第九,基础设施自动化(Infrastructure Automation)
基础设施自动化,如 CI/CD 的长足发展,大大降低了构建、发布、运维工作的复杂性。
由于微服务架构下,运维的服务数量比起单体架构来说,要有数量级的增长,所以使用微服务的团队,会更加依赖于基础设施的自动化。毕竟,人工是无法运维成百上千,乃至成千上万级别的服务的。
总结
从以上对微服务的定义和特征的解读当中,可以明显地感觉到,微服务追求的是更加自由的架构风格,它摒弃了 SOA 中几乎所有可以抛弃的约束和规定,提倡以“实践标准”代替“规范标准”。可是,如果没有了统一的规范和约束,以前 SOA 解决的那些分布式服务的问题,不又都重新出现了吗?
的确,服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通讯、事务处理等问题,在微服务中,都不再会有统一的解决方案。
在微服务时代中,软件研发本身的复杂度应该说是有所降低,一个简单服务,并不见得就会同时面临分布式中所有的问题,也就没有必要背上 SOA 那百宝袋般沉重的技术包袱。微服务架构下,我们需要解决什么问题,就引入什么工具;团队熟悉什么技术,就使用什么框架。
虽然微服务架构对普通的服务开发人员十分友好,但是对于架构者来说却是满满的恶意,因为它对架构能力的要求可以说是史无前例。要知道,技术架构者的第一职责就是做决策权衡,有利有弊才需要决策,有取有舍才需要权衡。如果架构者本身的知识面不足以覆盖所需要决策的内容,不清楚其中的利弊,也就不可避免地会陷入选择困难症的困境之中。
附
此文章为2月Day5学习笔记,内容来源于极客时间《周志明的软件架构课》