以下内容是我自己的理解，不保证正确，可能是对的，也可能把你引到沟里，通过判断你自己。更多详情，请观看直播揭开她的神秘面纱——零基础搭建属于你自己的服务治理框架因为一些原因，我们在服务，我们公司研发了一套服务治理框架。当时老虎吓了一跳，赶紧在手机上记下关键词：“面向服务”、“服务治理”、“服务治理框架”。回去后，我立即寻找。感觉很高级，但是不明白为什么要面向服务。什么是服务治理？很多文章一上来就直接说他们的服务治理很NB，但是对于新人来说，总有一种天马行空的感觉。所以这次希望从架构的演化入手，一步步讲解，希望能让大家豁然开朗。总体思路：业务的解耦导致服务的出现，多套服务出现代码冗余，管理不便最终导致服务治理的出现。服务化的出现想象着京东的发展（都是我杜撰的）。最初是一个类似ecshop的简单购物网站，由A团队迭代开发。突然有一天运营发现我们需要一个社区来增加用户粘性。招聘，组件团队，京东这个时候已经够大了，代码也很复杂。如果新团队（cnameB）开发社区，在原有基础上开发补丁是不合适的，所以我最终决定开发一个全新的。系统。既然是同一家公司，用户没有理由重新注册社区吧？应该是用户在www.jd.com/login登录过，然后在bbs.jd.com论坛中获取用户的基本信息。那么如何获取论坛用户的基本信息呢？为了新手更好理解，我随机制定了一个方案：用户登录www.jd.com/login后，www.jd.com服务器在客户端*.jd.com下保存一个对称加密的cookie。然后bbs.jd.com服务器拿到客户端的cookie并解密，得到一个json字符串，{uid:xxxx,username:'xxx',token:'xxxx'}最后bbs.jd.com服务器取uid+token去京东提供的一个API进行验证。验证通过后，就认为用户已经登录了。于是，A组和B组就愉快地合作了一段时间。随着业务的发展，账户变得越来越复杂。比如我们绑定越来越多的社交账号，还有很多邮箱、手机号登录、企业号、子号、会员等级等服务。我们都知道开发中高内聚低耦合的原则。最终A队老司机将原账号相关的代码分离出来，独立部署。分配域名account.jd.com。这样所有用户登录account.jd.com，A组和B组都调用account.jd.com的接口进行验证（内网ip:端口）。有一天灾难发生，账户中心集群被ddos攻击，ip直接被机房封了，但是A组和B组都不知道，很多请求在验证用户身份的时候被封了认证接口。结果请求越来越多，超时时间设置的越长，网站越卡。A队和B队都吸取了教训，制定了如下计划：定期检查账户中心服务的健康状况，比如一分钟一次。如果发现服务不可用，那么会将该服务的状态缓存10分钟（不可用），在此期间继续进行健康检查。如果发现服务可用，则状态将更改为服务可用。当发现服务不可用时，直接抛出异常，而不是阻塞等待。三方都添加了提醒，服务不可用时会收到提醒。更多的服务被抽离出来，更多的团队出现继续发展业务，出现了京东大药房，专门卖药，需要调用京东现有的财务系统。通过循环上述逻辑，金融系统变得独立。大型药店还需要调用账户中心的服务和金融服务。还要部署之前在TeamA和TeamB上的同一套容错代码服务商ip:port的变更所有服务用户代码的变更修改，新的ip:port用于开会和开会提出服务治理。现在系统的代码被A/B/C/D各个团队使用，更新地址需要手动更新。我们能做到吗？服务提供者地址更新，可以推送给所有服务消费者。过去，A和B管理着账户中心服务的服务。事实上，一套通用的解决方案就可以创建一个平台或服务（服务治理的原型）。A/B/C/D都依赖我的服务（服务治理的雏形），然后通过这个服务来管理每一个服务。也就是说，现在的服务治理是对各种服务进行管理。目前有两个功能，服务注册，服务订阅，服务推送。a服务商说过几天我们要做压力测试，所以请不要要求我们192.168.0.10，你们都要求192.168.0.11。哦！也就是权重，如果把前者的权重调整为0，好吧，所有的服务商可能都有这个需求。那么服务治理也是承包的。b服务商说你下单时打我们192.168.0.12，查单时打我们192.168.0.13或192.168.0.14。哦！这不就是我们的读写分离方式吗？OK，我们在服务治理中加入路由功能。服务提供者只需要动态配置，我们会动态推送给消费者。服务治理的提升会议实质：我们的服务治理中心需要一个注册中心统计谁提供了哪些服务，然后消费者，在启动服务的时候，像注册中心一样发送请求，我们需要哪些服务，注册中心推送提供商的服务信息。我们的服务管理中心需要一个监控中心来统计每项服务的提供次数、服务响应时间、服务的健康状态。对于服务提供者和服务消费者之间的通信，我们还是不用http吧，我们改成自定义协议，自己封装一套rpc协议就是我们的良药，这样我们就可以像调用远程方法一样usingalocalmethod（这个php理解可能有点莫名其妙，建议学习java，java是每个老司机都绕不过去的坎），服务提供者和服务消费者之间最好使用长连接减少每次请求连接NetworkI/O的时间消耗和连接时间。这个rpc协议也是我们服务治理指定的。目前为止就这样了！还没听够，老铁，看直播了解更多揭开她的神秘面纱——零基础搭建自己的服务治理框架https://segmentfault.com/l/15...
