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调用和服务注册，对于服务治理和监控，以及动态管理和鉴权控制几乎很少有开源的。在大家选择开源产品的时候，需要根据自己的实际情况，做必要的改造才能打造出真正适合自己的产品。