<强>第一部分:微服务的诞生,演变以及应用策略
记者:近几年来,微服务架构设计方式被提出并在越来越多的企业中得以实践和落地,但对于刚开始接触微服务的人来说,还是不知道要从哪些方面开始了解。您能否结合软件架构的发展历史,聊聊微服务的发展与特征。
梁鑫:微服务本质上是一种架构的风格,如果要了解微服务,我认为需要先了解整个架构的发展脉络。
软件架构,总是在不断的演进中。如果把时间退回到二十年前,当时企业级领域研发主要推崇的还是C/S模式,PB,德尔福这样的开发软件是企业应用开发的主流。
随着时间的推移,我们发现标准化的客户端存在一些弊病,比如我有一千个终端,升级版本需要每一台终端都升级,这是非常麻烦的。然后,企业应用研发开始向互联网学习,把浏览器作为客户端来使用,就可以避免这个问题,因此,基于浏览器的B/S架构开始渐渐流行起来。
刚开始的时候是ASP,之后又出现了JSP,因为Ja.va的预编译模式,让性能有了非常大的提升,随后基于Ja.va语言的J2EE架构就变得越来越流行。至此,架构经历了从传统的C/S模式到B/S模式的转变。
B/S架构初期基本都是单体架构,各个系统比较独立,他们之间往往不需要进行交互,即使存在一些交互,也大多是数据层面的。那个阶段ETL工具发展得很快,就是为了解决这样的数据孤岛问题。
随着企业应用越来越多,系统之间相互的关系也越来越密切,系统之间实时交互访问的需求也越来越多。这个时候工程师们发现,不管是什么语言开发的软件,基本都支持一种叫做XML的语言,于是提出一种实时交互的技术解决方案:通过XML语言来进行企业应用系统之间的远程调用。由此,SOA的概念被提了出来,网络服务开始流行。
当第二波互联网浪潮来临后,很多公司为了适应更加灵活的业务发展,用基于HTTP协议和Restful的架构风格替代了原先笨重的网络服务,简洁清晰的JSON替代了XML。同时SOA架构中常常采用服务总线技术,无疑是给系统架构增加了一个异常麻烦的瓶颈。如果使用注册和发现的机制,让服务进程之间直接进行调用,更适合企业应用的发展。这就是微服务架构从技术方面来说的历史脉络。
在《微服务设计》中界定微服务有两个基本原则:松耦合,高内聚,即“把因相同因素变化的事情聚集在一起,把因不同因素变化的事情区隔开来。”至于微服务大小的划分并没有统一的标准,通俗地说,就是你觉得它的大小差不多,同时符合“松耦合,高内聚”的原则就可以。
微服务有很多的好处,大致列举一些。
<李>异构:微服务可以帮助我们轻松采用不同的技术,并且理解这些新技术的好处。尝试新技术通常伴随着风险,但如果把服务切得很小了,总会存在一些点让你可以选择一个风险最小的服务采用新技术,并降低风险。 <李>弹性:很明显,微服务可以很好地处理服务不可用和功能降级的问题,因为它可以形成很多个节点。 <李>隔离:微服务架构将系统分解为独立运行单元,给系统带来更好的隔离性,独立的微服务在发生异常时更容易定位和隔离问题,隔离性也是服务扩展性的基础。 <李>扩展:庞大的单体服务只能作为一个整体进行扩展,即使系统中只有一小部分模块存在性能问题,也需要对整个系统进行扩展。而微服务架构可以根据性能需要对不同的模块进行水平扩展。 <李>部署简单:在微服务架构中,各个服务的部署是独立的,这样就可以更快地对特定部分的代码进行部署。服务出现问题也更容易快速回滚,同时敏捷的交付和部署带来了更好的业务需求响应体验。 <李>灵活:在微服务架构中,系统会开放很多接口供外部使用,当情况发生改变时,可以使用不同的方式构建应用。把单体应用分解成多个微服务,可以达到可复用,可组合的目的。
记者:据悉,您之前发表过一篇文章“公司为什么需要建立一套统一的开发框架?”,您认为公司建立统一开发框架是为了解决什么问题?
梁鑫:这是一个仁者见仁智者见智的问题,每个人的出发点都不一样,有的人可能主张需要统一,有的人则可能排斥统一,结合我的经历和实践来看,我认为公司是需要建立统一开发框架的。
近十年,互联网的发展颠覆了很多传统行业,很多新兴公司如雨后春笋般的冒了出来,它们的业务增长非常快,公司规模也越来越大。这得益于中国经济的高速增长和互联网的快速发展。但这种高速的发展过程中伴随而来的是不可忽视的弊端:
回归架构本质,重新理解微服务
