服务化的过去、现在和未来

服务化毫无疑问是技术圈一直火热的buzzword,而且其实已经非常多年了,这在日益更新的技术圈还挺神奇的,作为在服务化这个领域还从事过比较多年的人,觉得值得写一篇文章来说说我眼里的服务化的过去、现在和未来。

启蒙阶段

我应该是从2006年学习OSGi的时候开始第一次接触Service这个概念,不过OSGi的Service还指的的是单机应用,和之后服务化更多的是应用在分布式应用领域有挺大差别,但也有些共通之处,例如OSGi中的Service也同样具备定义、注册、发现这些机制,我之所以后来能加入淘宝估计也是因为我对OSGi Service这块的经验。

SOA落地阶段

2008年在淘宝我开始淘宝服务框架(HSF)的编写,和业务研发团队一起推进淘宝的服务化,这个时候的SOA火爆的不行,但更多的也只是概念,缺乏非常细节的落地Guideline或框架,这个时候业界的SOA的实现主要倡导两种方式,一种为用xml方式描述的service,例如WSDL,另一种则是esb。

我在设计HSF的时候,认为xml方式描述的service太复杂,而且其实也没有很清晰的指导例如服务的注册/发现应该怎么实现,尤其是在有集群、负载均衡场景的大型分布式系统中,更不用说服务化后会带来什么问题;至于esb,我认为在一个高并发的系统中,esb会成为极大的瓶颈点,最终导致系统的风险,所以最终我决定自己探索一个可用于落地SOA的服务框架到底应该怎么做,从而让大家基于这个框架就可以去做服务化,而不是还得先解读这个概念。

但由于缺乏经验,HSF的设计是出了挺多问题的,在 系统设计之解决核心问题的设计 这篇文章里基本都说到了,在这就不再去重复,最后总结下来就是我们可以看到一个服务框架的特征是:

  1. 简单的和单机开发框架集成的服务定义方式,例如在HSF中就是通过spring的bean定义方式来发布、订阅服务;

  2. 服务注册/发现机制,HSF采用的是引入一个ConfigServer来实现;

  3. 服务寻址和负载均衡,HSF采用的是无中心化的软件负载均衡方式,这个方式为支持可水平伸缩的服务调用是奠定了很好的基础的;

  4. 服务Tracing,HSF采用的是类似Google Dapper的方式,自己实现了一个内部代号为EagleEye的东西,以跟踪一个复杂的服务调用过程,这个对排查问题而言真的是至关重要,如果没有Tracing,服务化后的一堆问题是很麻烦的。

有了一个服务框架后呢,相对来说服务化就不是那么一个停留在概念阶段的东西,但对于服务化而言,服务框架不是全部,只是个基座而已,服务框架解决的更多的是服务化的技术问题,但服务化还有另外的核心问题是业务系统本身怎么服务化,应该把什么抽象为服务,服务的粒度怎么把控,这不是框架能搞定和指导的,这就得靠业务架构师了,而且除了这个外,服务化还会带来巨大的变化是组织结构需要相应的变化,因为在服务化之前,通常分工是不会太明晰的,而服务化后,就会有这样的要求,这对很多企业来说,是推进服务化最难的地方。

回顾这个阶段的话,可以看到的是这个阶段更重要的是让SOA这个概念有了一个更为清晰的可落地的框架出现,从而大家不用在纯粹的技术概念层面去争吵,比较概念这玩意吵个十年都没问题,框架的出现使得大家去落地服务化更多的进入了真正的实操阶段,去思考业务系统应该怎么抽象和定义服务,组织结构需要相应的如何调整。

淘宝大概在2009年可以认为服务化就进入了比较成熟的阶段了(那个时候差的主要是Tracing),在那之后如果看中国范围的企业,可以看到的是更多的互联网公司开始进行服务化的改造,由于当时开源界完全没有可用的服务框架,各家基本都自己打造,不过思想基本类似;如果视野放宽到全球的互联网公司,会看到google、facebook、ebay等其实是在更早的时候就完成了服务化的改造,并且google做的分享(Jeff Dean有一次在Stanford的分享讲到了Google的服务化)或者发表的一些论文(例如影响巨大的Dapper)里都可以看到对服务框架的一些组件的定义,只是没有那么系统化的说一个服务化的框架的组成,所以这样去看的话,阿里的整个服务化进程,通过分享以及后面开源的dubbo,对中国的企业进行服务化改造还是起到了一些帮助的。

微服务?

又过了很多年,SOA好像越来越不火了,突然有个新的概念:微服务火起来了,我到现在都没搞清楚微服务和淘宝在08年做的服务化的区别到底是什么,看了很多解读,我也还是不得要领,有见解的同学欢迎评论指导下,所以我对微服务就不做什么阐述了,这个对服务化唯一的好处我觉得就是又吸引了巨多人的关注。

Service Mesh

这个是继微服务后在服务化领域最火的概念了,同样,目前这东西和当年SOA一样,我觉得也更多的还只是概念,尽管已经有Istio、Envoy、RSocket、Knative等等东西出现了,但实践层面还挺缺少的,目前还是一个战国时代。

Service Mesh这概念我之前也一直看不太懂,现在我基本上认可Service Mesh确实是推进服务化领域发展的一个方法,原因是我认为Cloud Native一个很核心的点是打造一套开放、公共的技术体系,而看起来Service Mesh是实现这个的不错的思路,它会带来两个好处:

  1. 对客户而言,采用Service Mesh使得在vendor no lock-in上有了很大的帮助,因为只要各家vendor在功能层面能差不多,mesh的sidecar方式使得客户非常容易切换vendor,不影响业务层面的代码;

  2. 对云计算厂商而言,采用Service Mesh使得在对接多种协议层面有了很简单的实现方法,这样就可以很好的实现同一技术领域不同产品的互通,这对一个开放、公共的技术体系而言挺重要的,同样也会使得客户move to cloud变的更加容易。

所以我认为Service Mesh最后成的那家一方面是实践的经验,另一方面则是对不同领域的不同技术产品协议的对接丰富度,我也非常看好service mesh成为新一代的服务化的实现方式。

总结

服务化的技术经过这么多年的发展,经历了SOA概念,到帮助SOA落地的服务框架,到微服务,到未来的Service Mesh,现在仍然活跃在技术的舞台上,并且其实大部分企业还在经历多数互联网公司早期服务化的阶段,当然,诉求我觉得差别很大,互联网公司做服务化多数其实是为了解水平伸缩的问题,现在大部分企业服务化更多的是为了解业务互通、大规模研发团队协作的问题,所以仍然非常看好这个领域的发展。

欢迎关注我的公众号hellojavacases,

聊聊编程能力的高级进阶,

聊聊系统设计,

聊聊技术方向,

聊聊职业生涯的发展。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章