对微服务的基本理解 顾名思义,微服务要从两个方面来理解,一个是“微”,一个是“服务”。体型小到一定程度才能叫“微”,这个程度是什么呢?一个身高1米6,体重90斤的MM,我们说她苗条。微服务也一样,根据亚马逊CEO Bezos给出的有趣定义,单个微服务的设计、开发、测试和运维的所有人加在一起吃饭,只需要两个批萨就够了,这是就是著名的two pizza team rule。 具备什么样的能力才能算是“服务”?这个话题很大,我这里按照自己的片面理解总结一下,所谓服务就一定会区别于系统的功能,服务是一个或者一组相对的较小且独立的功能单元,是用户可以感知的功能最小集,比如:购物车,订单,信用卡结算等都可以作为单个服务独立提供。 这个理解显然不够深刻,为了进一步理解为什么微服务在近两年业界迅速窜红,理解为什么微服务会被认为是IT软件架构的未来方向,就要理解为什么我们需要微服务?它能给企业带来什么价值。传统企业的IT软件大多都是各种独立系统的堆砌,这些系统的问题总结来说就是扩展性差,可靠性不高,维护成本高。后来有了一个叫SOA的软件架构专门针对这些问题给出了一套解决方案,很多企业也因此将自身IT系统迁移到SOA架构上。 但是,由于SOA早期均使用了总线模式,这种总线模式是与某种技术栈强绑定的,比如:J2EE。这导致很多企业的遗留系统很难对接,切换时间太长,成本太高,新系统稳定性的收敛也需要一些时间。最终SOA开起来很美,但却成为了企业级奢侈品,中小公司都望而生畏。 依然SOA 微服务,从本质意义上看,还是SOA架构。但内涵有所不同,微服务并不绑定某种特殊的技术,在一个微服务的系统中,可以有Java编写的服务,也可以有Python编写的服务,他们是靠Restful架构风格统一成一个系统的。 最粗浅的理解就是将微服务之间的交互看作是各种字符串的传递,各种语言都可以很好的处理字符串,所以微服务本身与具体技术实现无关,扩展性强。另一个不同是微服务架构本身很轻,底层也有类似于SOA的总线,不过非常轻薄,现在看到的就两种方式:MQ和HTTP,而HTTP都不能完全等同于总线,而仅仅是个信息通道。 所以,基于这种简单的的协议规范,无论是兼容老旧系统,还是上线新业务,都可以随着时代的步伐,滚动升级。比如:你去年还在使用.NET技术,今年就可以平滑的过度到Go了,而且系统已有服务不用改动。所以微服务架构,既保护用户已有投资,又很容易向新技术演进。 微服务水下的冰山 人月不是银弹,微服务更不是银弹,好像软件微服务化了,软件系统就能够应对各种问题了。其实微服务的水面下藏着巨大的冰山。下面是微服务提供的能力,以及背后需要付出的代价。
综上所述,微服务关键其实不仅仅是微服务本身,而是系统要提供一套基础的架构,这种架构使得微服务可以独立的部署、运行、升级,不仅如此,这个系统架构还让微服务与微服务之间在结构上“松耦合”,而在功能上则表现为一个统一的整体。 这种所谓的“统一的整体”表现出来的是统一风格的界面,统一的权限管理,统一的安全策略,统一的上线过程,统一的日志和审计方法,统一的调度方式,统一的访问入口等等。 这些系统性的功能也需要有一些服务来提供,这些服务不会直接呈现给最终用户,也就是微服务系统冰山下面的部分,我们可以简称它为微服务系统的“底座”。所有的微服务都像一个APP,插在这个底座的上面,享受这个底座提供的系统能力比如:元数据存放、灰度发布、蓝绿部署等等。 微服务系统底座 一个完整的微服务系统,它的底座最少要包含以下功能:
以下功能不是最小集的一部分,但也属于底座功能:
令人困惑的几个问题 微服务的底座是不是必须的? 是的,基本上是必须的。你可以不用代码实现一个资源管理服务,可以手工用Excel管理你的所有机器资源,但是不代表微服务系统没有这个功能,只不过这个功能是人工实现的。 再举个例子,日志系统如果只是简单的打印文件,那么多个微服务的日志就需要手工收集,人工分类和筛选。所以,微服务的底座最小集一定会存在,问题是看怎样实现它。 这里仅仅是总结了对微服务系统的基本理解,而实现这个架构有很多技术,这里不进行详细展开。实践方面,推荐王磊的《微服务架构与实践》,他描述了使用Ruby相关的技术实现了一整套微服务系统,特别是书中后面的实践部分讲解了如何将已有的系统演化为微服务架构,是很好的参考和指导材料。 是不是所有软件都能做微服务? 这个命题有些微妙,也很难说清楚,回答这个命题本身就是一种挑战,可能最终也没有正确答案。不过,我还是把我自己的理解写在这里,让大家去拍砖。在我这里,答案是否定的。我只需举出一个反例,比如:存储系统,其架构是传统的分层架构,每一层都使用下面一层的服务,并为上一层提供服务。虽然可以将这种架构调整为基于服务的架构,但没办法做成微服务。 区别在哪里呢?核心的区别在于独立性上,微服务大多是可以独立的运行和使用的,而存储这种非常底层和基础的系统,每层部件都不能单独被使用,比如:Pool管理、CHUNK管理、VOL管理、NFS文件系统,这些功能都无法离开另外一些功能而独立运行,要对外提供可用的存储功能,一大堆功能必须一起上。这种系统做到极致,最多也就能够使其部件可以独立的部署和升级,俗称打热补丁。 这也就是为什么这种底层传统系统架构通常是单块架构的原因。由于单块架构的各个部分调用关系紧密,做成微服务后系统集成成本会大大增加,不仅如此,这样的架构做成微服务并不能提高交付效率,因为各个部分根本就无法独立的运行和测试。 什么样的软件做成微服务? 能不能做成微服务,取决于四个要素:
针对于小、轻、松都是可以通过某些技术手段达到目的,而独立的部署和运行,则是和业务本身有关系,如果你这个系统提供的业务是贴近最终用户的,并且这些功能之间的耦合性很小,则微服务就可以按照业务功能本身的独立性来划分,则这类系统做成微服务是非常合适的。 如果系统提供的业务是非常底层的,如:操作系统内核、存储系统、网络系统、数据库系统等等,这类系统都偏底层,功能和功能之间有着紧密的配合关系,如果强制拆分为较小的服务单元,会让集成工作量急剧上升,并且这种人为的切割无法带来业务上的真正的隔离,所以无法做到独立部署和运行,也就更加无法做到真正的微服务了。 ▽
喜欢我们的会点赞,爱我们的会分享!
|
|