微服务架构(Microservices)
微服务是一种通过多个小型服务组合来构建单个应用的架构风格,这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言,不同的数据存储技术,运行在不同的进程之中。服务采取轻量级的通讯机制和自动化的部署机制实现通讯与运维。
“微服务”这个技术名词最早在2005年就已经被提出,它是由Peter Rodgers博士在2005年度的云计算博览会(Web Services Edge 2005)上首次使用,当时的说法是“Micro-Web-Service”,指的是一种专注于单一职责的、语言无关的、细粒度Web服务(Granular Web Services)。“微服务”一词并不是Peter Rodgers直接凭空创造出来的概念,初生的微服务可以说是上文所讲的《演进中的架构之SOA时代》所催生的产物,就如同EJB推广过程中催生了Spring和Hibernate那样。这一阶段的微服务是作为一种SOA的轻量化的补救方案而被提出的。时至今日,在英文版的维基百科上,仍然将微服务定义为一种SOA的变种形式,所以微服务在最初阶段与SOA、Web Service这些概念有所牵扯也完全可以理解,但现在来看,维基百科对微服务的定义已经颇有些过时了。
What is microservices
Microservices is a software development technique — a variant of the service-oriented architecture (SOA) structural style.
—— Wikipedia,Microservices
微服务的概念提出后,将近10年的时间里面,都并没有受到太多的追捧,如果只是对现有SOA架构的修修补补,确实是难以唤起广大技术人员的更多激情了。不过,在这10年时间里,微服务本身也在思考、蜕变。2012年,在波兰克拉科夫举行的“33rd Degree Conference”大会上,Thoughtworks首席咨询师James Lewis做了题为《Microservices - Java, the Unix Way》的主题演讲,其中提到了单一服务职责、康威定律、自动扩展、领域驱动设计等原则,却只字未提SOA,反而提倡应该重拾Unix的设计哲学(As Well Behaved Unix Services),这点仿佛与笔者在前一节所说的“初心与自省”在遥相呼应。微服务已经迫不及待地要脱离SOA的附庸,成为一种独立的架构风格,也许,还将会是SOA的革命者。
微服务真正的崛起是在2014年,相信阅读此文的大多数读者,也是从Martin Fowler与James Lewis合写的文章《Microservices: a definition of this new architectural term》中首次了解到微服务的,并不是指各位一定读过这篇文章,或者准确地说,今天各位所了解的“微服务”是这篇文章中提出的“微服务”。在此文中,定义了现代微服务的概念:“微服务是一种通过多个小型服务组合来构建单个应用的架构风格,这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言,不同的数据存储技术,运行在不同的进程之中。服务采取轻量级的通讯机制和自动化的部署机制实现通讯与运维”。此外,文中列举出了微服务的九个核心的业务与技术特征,笔者将其一一列出并解读如下:
《Microservices》一文中对微服务特征的描写已经相当具体了,此文中除了定义的微服务是什么,还专门申明了微服务不是什么——微服务不是SOA的变体或衍生品,应该明确地与SOA划清了界线,不再贴上任何SOA的标签。如此,微服务的概念才算是一种真正丰满、独立、具体的架构风格,为它在未来的几年时间里如明星一般闪耀崛起于技术舞台铺下了理论基础。
This common manifestation of SOA has led some microservice advocates to reject the SOA label entirely, although others consider microservices to be one form of SOA , perhaps service orientation done right. Either way, the fact that SOA means such different things means it's valuable to have a term that more crisply defines this architectural style
由于与SOA具有一致的表现形式,这让微服务的支持者更加迫切地拒绝再被打上SOA的标签,尽管有一些人坚持认为微服务就是SOA的一种变体形式,也许从面向服务方面这个方面来说是对的,但无论如何,SOA与微服务都是两种不同的东西,正因如此,使用一个别的名称来简明地定义这种架构风格就显得更有必要。
—— Martin Fowler / James Lewis,Microservices
从以上微服务的定义和特征中还可以明显地感觉到,微服务追求的是更加自由的架构风格,摒弃了几乎所有SOA中可以抛弃的约束和规定,提倡以“实践标准”代替“规范标准”。可是,如果没有了统一的规范和约束,以前SOA所解决的那些分布式服务的问题,不也就一下子都重新都出现了吗?的确如此,服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通讯、事务处理,等等,这些问题,微服务中不再会有统一的解决方案,即使只讨论Java范围内会使用到的微服务,光一个服务间通讯问题,可以列入解决方案的候选清单的就有:RMI(Sun/Oracle)、Thrift(Facebook)、gRPC(Google)、Motan2(新浪)、Finagle(Twitter)、Arvo(Hadoop)、JSON-RPC、REST,等等;光一个服务发现问题,可以选择的就有:Eureka(Netflix)、Consul(HashiCorp)、Zookeeper(Apache)、Etcd(CoreOS)、CoreDNS(CNCF),等等。其他领域的情况也是与此类似,总之,完全是八仙过海,各显神通的局面。
微服务所带来的自由是一把双刃开锋的宝剑,当软件架构者拿起这把宝剑,一刃指向SOA定下的复杂技术标准,将选择的权力夺回的同一时刻,另外一刃也正朝向着自己映出冷冷的寒光。微服务时代中,软件研发本身的复杂度应该说是有所降低,一个简单服务,并不见得就会同时面临分布式中所有的问题,也就没有必要背上SOA那百宝袋般沉重的技术包袱。需要解决什么问题,就引入什么工具;团队熟悉什么技术,就使用什么框架。此外,像Spring Cloud这样的胶水式的全家桶工具集,通过一致的接口、声明和配置,进一步屏蔽了源自于具体工具、框架的复杂性,降低了在不同工具、框架之间切换的成本,所以,作为一个普通的服务开发者,作为一个“螺丝钉”式的程序员,微服务架构是友善的。可是,微服务对架构者是满满的恶意,对架构能力要求已提升到史无前例的程度,笔者在这部文档的多处反复强调过,技术架构者的第一职责就是做决策权衡,有利有弊才需要决策,有取有舍才需要权衡,如果架构者本身的知识面不足以覆盖所需要决策的内容,不清楚其中利弊,恐怕也就无可避免地陷入选择困难症的困境之中。
微服务时代充满着自由的气息,微服务时代充斥着迷茫的选择。软件架构不会止步于自由,微服务仍不是架构探索终点,如果有下一个时代,我希望是信息系统能同时拥有微服务的自由权利,围绕业务能力构建自己的服务而不受技术规范管束,但同时又不必以承担自行解决分布式的问题的责任为代价。管他什么利弊权衡!小孩子才做选择题,成年人全部都要!
周志明,腾讯云最具价值专家(TVP),Java技术、机器学习和企业级开发技术专家,现任远光软件研究院院长,机器学习方向博士, 开源技术的积极倡导者和推动者,对计算机科学和相关的多个领域都有深刻的见解,尤其是人工智能、Java技术和敏捷开发等领域。曾受邀在InfoQ和IBMDeveloperWorks等网站撰写技术专栏。
著有畅销书多本。著有《智慧的疆界》、《深入理解Java虚拟机》、《深入理解OSGi》,翻译了《Java虚拟机规范》等著作。其中《深入理解Java虚拟机》第1版出版于2011年,已经出至第3版,累计印刷超过35次,销量30万册;不仅销量好,而且口碑更好,是中文计算机图书领域公认的、难得一见的佳作。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。