毕大从自身设计HSF的角度出发谈服务化这回事

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

原创： bluedavy HelloJava  9月18日

服务化毫无疑问是技术圈一直火热的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，现在仍然活跃在技术的舞台上，并且其实大部分企业还在经历多数互联网公司早期服务化的阶段，当然，诉求我觉得差别很大，互联网公司做服务化多数其实是为了解水平伸缩的问题，现在大部分企业服务化更多的是为了解业务互通、大规模研发团队协作的问题，所以仍然非常看好这个领域的发展。