服务治理深刻浅出（1）- 服务治理出现的必要性探索

如下内容都是本身的理解，不保证正确，多是对的，也可能把你带沟里，本身甄别。

更多详情请看直播 揭开她的神秘面纱 - 零基础构建本身的服务治理框架

https://segmentfault.com/l/15...

好久以前听别人分享他们的架构，总会说，由于某某缘由，咱们进行服务化，咱们公司开发了一套服务治理框架。

当时虎躯为之一震，赶忙在手机上记下关键词：“服务化”、“服务治理”、“服务治理框架”。
回去以后立刻搜索，以为很高大上，弄不懂，为何要服务化，到底什么是服务治理啊？
不少文章一上来就直接讲他们的服务治理多 NB，对于新人来讲却总有一种镜花水月的感受，那么我此次，但愿从架构的演变出发，逐步说明，但愿能让你们豁然开朗。

整体思路：业务的解耦使得服务化的出现，多套服务化的出现代码冗余，管理不便最终使得服务治理的出现。

服务化的出现

假想一个京东的发展路程（都是我虚构的）。

1. 最初是一个简单的相似的 ecshop 的购物网站，由 A 团队在迭代开发。忽然有一天运营发现，咱们须要一个社区，增长用户的粘性。
2. 招兵买马，组件团队，这个时候京东已经足够庞大，代码也很复杂，新团队（cname B）开发一个社区，若是在原来基础上打补丁式的开发，反而不合适，因此最终决定开发一套全新的系统。既然是同一家公司，那么没有理由要用户从新在社区注册吧？应该是用户在 www.jd.com/login 登陆了，而后在论坛 bbs.jd.com 就应该能获取用户的基本信息。

3. 那怎么在论坛里获取用户的基本信息呢？
   为了新人更好的理解，我随便编了一种方案：

   • 用户在 www.jd.com/login 登陆以后，www.jd.com 服务器端把一份对称加密的 cookie 存在客户端的 *.jd.com 下。
   • 而后 bbs.jd.com 服务器端拿到客户端的 cookie 解密以后，获得一个 json 串，{uid:xxxx,username:'xxx',token:'xxxx'}
   • 最后 bbs.jd.com 服务器端拿着 uid + token 去 www.jd.com 提供的一个 api 作验证，验证经过以后，算用户已经登陆。
4. 如此，A 团队和 B 团队一块儿携手幸福合做了一段时间。
5. 随着业务的发展，帐号变得愈来愈复杂，好比咱们绑定的社交帐号愈来愈多，各家邮箱也不少，手机号登陆，企业帐号、子帐号、会员等级等等业务。
6. 咱们都知道开发的原则的高内聚，低耦合。最后 A 团队的老司机，将原来的帐号相关的代码，独立出来单独部署。分配域名account.jd.com。这样用户都统一到account.jd.com进行登陆， A 团队和 B 团队都调用account.jd.com的接口来验证（走内网 ip:port ）。

灾难的发生

某一天帐号中心集群被 ddos 攻击，被机房直接封 ip 了，而 A 团队和 B 团队都不知道，不少请求都阻塞在了用户的身份鉴权接口的验证上。致使请求愈来愈多，timeout 时间设置的也比较长，这样网站都愈来愈卡。

A 团队和 B 团队都吸收了教训，作出了以下方案：

1. 周期性的去对帐号中心的服务进行健康，好比一分钟检测一次。
2. 若是发现服务不可用，那么就缓存服务的状态10分钟（unusable），期间继续不停的进行健康巡查，发现服务可用，则修改状态为服可用。
3. 发现服务不可用的时候，直接抛出异常，不在阻塞等待。
4. 三方都添加了报警，若是服务不可用，都会收到报警。

更多的服务的提取抽离，更多的团队出现

1. 业务继续发展，出现了京东大药房，专门卖药，须要调用京东目前的财务系统。循环上面的逻辑，财务系统独立出来了。
2. 大药房也要调用帐号中心的服务和财务服务。
3. 也要部署以前在 A 团队和 B 团队的那套容错代码。

服务提供方的变更

1. ip:port 的变更
2. 全部的服务使用者的代码都修改使用新的ip:port

开会开会 提出服务治理

1. 如今系统的代码都被 A/B/C/D 各个团队在用，地址更新了了还要手动更新了，咱们能不能作到，服务提供者地址更新了，能推送到全部服务消费者。
2. 以前 A,B 对帐号中心的服务作的服务的管理，其实一套通用的方案，能不能搞出来一个平台或者服务（服务治理的雏形），A/B/C/D 都依赖我这个服务（服务治理的雏形），经过这个服务再去管理各个服务。
3. 也就是如今这个服务治理的就是来管理各个服务，目前有两个功能，服务注册、服务订阅、服务的推送。
4. a 服务提供方说，咱们过几天要作压测，大家别不能请求咱们192.168.0.10，大家都请求192.168.0.11。哦！也就是权重，把前者的权重调为0，好，全部的服务提供方均可能会有这种需求。那么服务治理也承包了。
5. b 服务提供方说，大家写订单的时候调用咱们192.168.0.12，查订单的时候调咱们192.168.0.13或者192.168.0.14。哦！这不是我们的读写分离的套路么，行，咱们服务治理加个路由功能，服务提供者只要在动态的配置就行，咱们再动态推给消费者。

服务治理的完善

整理会议的精髓：

1. 咱们服务治理中心，须要一个注册中心，统计都有哪些人提供了哪些服务，而后消费者，在启动服务的时候，像注册中心发送请求，咱们须要哪些服务，注册中心推送提供者的服务信息。
2. 咱们服务治理中心，须要一个监控中心，统计各个服务提供的次数、服务响应的时间、服务的健康状态。
3. 服务提供者和服务消费者之间通讯，咱们就别走 http 了，咱们改为自定义协议，本身封装一套
   rpc 协议才是咱们的良药，这样咱们就像在使用本地方法同样调用远程的方法了（这个 php 理解可能有点莫名其妙，推荐学习 java，java 是每一个老司机绕不过的坎），最好是服务提供者和服务消费者之间使用长链接，减小每次请求链接的时间消耗和网络I/O。这个rpc协议也由咱们服务治理还给你们指定吧。

就写到这了吧！

还没听够，老铁，更多详情请看直播 揭开她的神秘面纱 - 零基础构建本身的服务治理框架

https://segmentfault.com/l/15...