多点生活的分布式服务框架DSF

编者按：J2EE异军突起之时，那些2层架构（web+后端）的人必定是崩溃的；而后spring以without ejb革命了，现在spring已渐成全家桶之势。SOA概念兴起之时，ESB相关的厂商大赚，而今老马又携微服务而来，受益者包括企业软件厂商，各云平台厂商等，眼花缭乱渐迷眼，各领风骚好几年！多点生活架构师陈泽洪本着【少谈些概念、多解决问题】的原则给我们分享他们用几个月完成的这一套分布式服务框架。近期中生代社群由ppmoney敖小剑同学分享的微服务架构非常干货，几近跨省追杀；本文同样是这样的干货，很干...

 

选择开源产品的时候，需要根据自己的实际情况，做必要的改造才能打造出真正适合自己的产品。多点生活通过一系列的减法和加法，打造出了自己的分布式服务化平台。

陈泽洪，多点架构师,此前曾在京东、蚂蚁金服工作

背景

多点生活成立于2015年初，1亿美元天使轮，和物美超市深度合作，目标是打造线上线下一体化的全渠道零售平台。技术研发团队基本上全  在成都，在成都JAVA好招人，所以基本上在多点内部就是JAVA一统天下了，也没有去考虑其他的语言了。10几个人，2个月时间，上线了第一版的业务系统，麻雀虽小五脏俱全，从APP到H5，从商品到购物车，从订单到交易，从会员到配送履约，十几个系统。为了快速开发，全部基于REST API，通过一个叫API Center的中心服务进行中转服务调用。

图1、早期的API Center

随着业务量的增长，3个月时间用户量就超过200万，业务系统不断增加，服务之间的调用变得越来越复杂，没有谁能完全理清楚服务之间的关系了。同时APICenter慢慢成为瓶颈，也占用了我们不少服务器资源，作为创业公司，还是要精打细算的。而且APICenter作为服务中心路由节点，所有的服务调用都走这里通过。有一次，我们的一个工程师出了一个bug，在一个死循环中不停调用某个服务，直接把APICenter搞挂了，所有服务都不能提供服务，只能简单粗暴重启服务或干掉问题服务。

图2、业务发展一年后的全景图

创业公司，时间宝贵，拿来主义

为了解决上面的问题，迫切要有一套分布式服务框架来解决这些问题，由于时间紧，人手有限，从头开发一个肯定是来不及了。所以我们本着拿来主义的原则选择了一个开源的框架来用，那就是dubbo。虽然dubbo并不是市面上最好、最新的服务框架，但是我们很多人对dubbo都很熟悉，使用成本低，于是就选择了它，本身我们只需要支持JAVA语言就够了。

先做减法，再做加法

dubbo相对来说是一个很老的框架了，功能很庞杂，有很多我们用不上的东西，同时有很多我们想要的功能却没有。于是我们第一步先做减法：精简内核，去掉所有不要的功能，干掉了差不多一半的功能；第二步：调整策略，修改测试发现的bug；第三步：添加我们必要的功能。2个人，1个月时间，就基本上改造完成了符合我们预期的分布式服务化框架。

图3、多点服务化框架DSF

核心功能点：

1、RPC [保持不变]

这块基本上没有做什么调整，直接沿用dubbo基于netty的长连接的传输，hessian的序列化，在满足我们的业务调用量的前提下，不引入更多的依赖，保持简单就好。

2、服务注册和发现[改进]

我们是基于Zookeeper来做服务注册与发现，也没有什么大的问题，而且几乎是现成的解决方案，不需要开发什么代码。随着我们开始多机房（混合云）部署，就创建了一个大的ZK集群，不同机房的应用优先连本地的ZK节点，优先调用本地机房的服务，当本地机房的服务不可用的时候，自动跨专线调用另外机房的服务。

这些功能本身dubbo并没有提供，需要我们代码来实现。但是由此带来了不少的运维复杂度，我们需要针对不同机房的应用部署打包配置不同的参数，以适应优先本地机房配置。于是我们就开发了我们自己的配置中心(Admiral)，可以用同一个打包部署文件，自动适配不同机房不同的参数来达到本地机房优先的原则。

图4、优先注册和调用本地服务

图5、基于配置中心，自动获取配置参数

3、监控与报警[新增]

监控对于一个系统来说是就像人的耳目，不可或缺。我们就在框架层无侵入的采集服务调用的关键指标：调用次数、响应时间、错误率等，然后基于开源的监控系统open-falcon来存储监控数据，通过内部的DMC报警平台通知应用负责人。对于监控数据，我们还从两个维度去监控数据：服务提供方维度，服务使用方维度。这样我们就可以在监控数据报警时，发现是哪一方出现问题了。比如，调用方发现响应时间很高，但是服务提供方的响应时间很低，那么问题就出在服务调用方或提供方到调用方的网络有问题。

图6、基于Open-falcon的服务调用监控

4、服务依赖管理[新增]

作为分布式服务平台，我们迫切需要知道服务的部署情况，服务的依赖情况，需要很直观的查看和搜索。这样就能清楚明白服务的调用关系，在升级服务之前可以一键邮件通知依赖方。同时还可以通过不同维度查看服务依赖：服务提供方视角、服务使用方视角、应用视角、服务视角、机器视角，以满足不同场景的需求。

图7、可视化的服务依赖关系

图8、服务依赖的明细

5、鉴权控制[新增]：

很多时候有些服务是不希望别人随意调用的，就需要增加鉴权管理。dubbo本身只提供服务注册层面的管理，没有提供服务级别的健全管理。我们就在框架层统一增加了鉴权token支持，通过简单的xml配置，只有提供了鉴权token key的调用方才能正常调用，否则会被拒绝。

6、动态配置[改进]：

有时候业务需要在不重启服务的情况下动态调整参数，比如：权重、超时时间等。dubbo原生的动态配置很简陋，几乎不太可能直接拿到生产环境使用。于是我们做了不少改进，在web页面上可视化动态调整参数，还可以指定参数生效的scope：服务提供方，服务调用方，全局配置，单一实例配置，应用级别，服务级别等，极大方便了线上发布调整。

图9、在线动态参数调整

7、在线验证[新增]：

因为我们用的是基于二进制协议的RPC调用，要想像rest api一样用postman之类的工具简单方便地无client调用验证服务API，其实是很麻烦的。为了解决有些纯后台的服务发布上线验证，我们就增加了在线验证功能，通过泛化调用，无需写调用方代码，直接在线可视化调用服务进行验证，极大地方便了研发测试验证。

图10、在线服务验证

8、调用链跟踪[待实现]：

作为分布式系统，服务的调用链跟踪对于问题的排查是非常有帮助的，鉴于开发人手不足，我们暂时没有提供这个功能，后续计划整合pinpoint，提供完善的调用链跟踪。

总结

通过这一系列的减法和加法，很快就打造出了多点生活自己的分布式服务化平台，其实市面上很多的服务化框架只提供了基本的RPC调用和服务注册，对于服务治理和监控，以及动态管理和鉴权控制几乎很少有开源的。在大家选择开源产品的时候，需要根据自己的实际情况，做必要的改造才能打造出真正适合自己的产品。

关注公众号，可享受不频繁的推送

 

 

12人点赞

 

微服务系列

 

作者：meng_philip123
链接：https://www.jianshu.com/p/8a956898b205
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。