摘要：服务化的出现假想一个京东的发展路程都是我虚构的。更多的服务的提取抽离，更多的团队出现业务继续发展，出现了京东大药房，专门卖药，需要调用京东目前的财务系统。
更多详情请看直播 揭开她的神秘面纱 - 零基础构建自己的服务治理框架以下内容都是自己的理解，不保证正确，可能是对的，也可能把你带沟里，自己甄别。
https://segmentfault.com/l/15...
很久之前听别人分享他们的架构，总会说，因为某某原因，我们进行服务化，我们公司开发了一套服务治理框架。
当时虎躯为之一震，赶紧在手机上记下关键词：“服务化”、“服务治理”、“服务治理框架”。
回去之后马上搜索，觉得很高大上，弄不懂，为什么要服务化，到底什么是服务治理啊？
很多文章一上来就直接讲他们的服务治理多 NB，对于新人来说却总有一种镜花水月的感觉，那么我这次，希望从架构的演变出发，逐步说明，希望能让大家豁然开朗。
服务化的出现总体思路：业务的解耦使得服务化的出现，多套服务化的出现代码冗余，管理不便最终使得服务治理的出现。
假想一个京东的发展路程（都是我虚构的）。
最初是一个简单的类似的 ecshop 的购物网站，由 A 团队在迭代开发。突然有一天运营发现，我们需要一个社区，增加用户的粘性。
招兵买马，组件团队，这个时候京东已经足够庞大，代码也很复杂，新团队（cname B）开发一个社区，如果在原来基础上打补丁式的开发，反而不合适，所以最终决定开发一套全新的系统。既然是同一家公司，那么没有理由要用户重新在社区注册吧？应该是用户在 www.jd.com/login 登录了，然后在论坛 bbs.jd.com 就应该能获取用户的基本信息。
那怎么在论坛里获取用户的基本信息呢？
为了新人更好的理解，我随便编了一种方案：
用户在 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 做验证，验证通过之后，算用户已经登录。
如此，A 团队和 B 团队一起携手幸福合作了一段时间。
随着业务的发展，账号变得越来越复杂，比如我们绑定的社交账号越来越多，各家邮箱也很多，手机号登录，企业账号、子账号、会员等级等等业务。
我们都知道开发的原则的高内聚，低耦合。最后 A 团队的老司机，将原来的账号相关的代码，独立出来多带带部署。分配域名account.jd.com。这样用户都统一到account.jd.com进行登录， A 团队和 B 团队都调用account.jd.com的接口来验证（走内网 ip:port ）。
灾难的发生某一天账号中心集群被 ddos 攻击，被机房直接封 ip 了，而 A 团队和 B 团队都不知道，很多请求都阻塞在了用户的身份鉴权接口的验证上。导致请求越来越多，timeout 时间设置的也比较长，这样网站都越来越卡。
A 团队和 B 团队都吸取了教训，做出了如下方案：
周期性的去对账号中心的服务进行健康，比如一分钟检测一次。
如果发现服务不可用，那么就缓存服务的状态10分钟（unusable），期间继续不停的进行健康巡查，发现服务可用，则修改状态为服可用。
发现服务不可用的时候，直接抛出异常，不在阻塞等待。
三方都添加了报警，如果服务不可用，都会收到报警。
更多的服务的提取抽离，更多的团队出现业务继续发展，出现了京东大药房，专门卖药，需要调用京东目前的财务系统。循环上面的逻辑，财务系统独立出来了。
大药房也要调用账号中心的服务和财务服务。
也要部署之前在 A 团队和 B 团队的那套容错代码。
服务提供方的变动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。哦！这不是咱们的读写分离的套路么，行，我们服务治理加个路由功能，服务提供者只要在动态的配置就行，我们再动态推给消费者。
服务治理的完善整理会议的精髓：
我们服务治理中心，需要一个注册中心，统计都有哪些人提供了哪些服务，然后消费者，在启动服务的时候，像注册中心发送请求，我们需要哪些服务，注册中心推送提供者的服务信息。
我们服务治理中心，需要一个监控中心，统计各个服务提供的次数、服务响应的时间、服务的健康状态。
服务提供者和服务消费者之间通信，我们就别走 http 了，我们改成自定义协议，自己封装一套
rpc 协议才是我们的良药，这样我们就像在使用本地方法一样调用远程的方法了（这个 php 理解可能有点莫名其妙，推荐学习 java，java 是每个老司机绕不过的坎），最好是服务提供者和服务消费者之间使用长连接，减少每次请求连接的时间消耗和网络I/O。这个rpc协议也由我们服务治理还给大家指定吧。
就写到这了吧！
还没听够，老铁，更多详情请看直播 揭开她的神秘面纱 - 零基础构建自己的服务治理框架https://segmentfault.com/l/15...
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/23263.html
摘要：也就使得企业在采用云服务时，多云管理成为首要痛点。而企业部署混合云战略时，最先解决的一大要务就是简化混合云的管理和部署，选择符合自身需求的多云管理平台。云管理和云连接多厂商异构云平台的统一管控是多云管理的基础。云计算作为业务战略发展的长期选择已成为行业共识，而混合云作为云计算领域的一匹黑马，开始被越来越多的企业采纳，成为主流的云计算模式，谷歌、微软、阿里云等已纷纷实施混合云部署战略。根据云星...
摘要：需求在了解了前面我们关于服务治理出现的必要性之后。我们知道服务治理是建立在众多服务基础之上的，那么，第一步，打通这些服务是基础，也就是我们常说的远程调用。上面执行远程调用也类似。 需求 在了解了前面我们关于服务治理出现的必要性之后。我们知道服务治理是建立在众多服务基础之上的，那么，第一步，打通这些服务是基础，也就是我们常说的 RPC 远程调用。要像调用本地方法一样调用远程服务器上的方法...
摘要：云计算十大关键词分别是云原生高性能混沌工程混合云边缘计算零信任优化治理数字政府低碳云企业数字化转型。当前，云原生与云安全呈加速融合趋势。 7月27日，由中国信息通信研究院、中国通信标准化协会主办的2021年可信云大会在京召开。中国信息通信研究院云计算与大数据研究所所长何宝宏在会上正式发布2021云计算十大关键词以及对应的重要发展趋势。 ...
摘要：目前，网易云轻舟微服务平台已经应用于银行证券视频监控物流工业等行业不少中大型企业，帮助其实施微服务化改造，建设符合行业特点的业务中台，支撑企业数字化战略的落地。 微服务技术由于天生支持快速迭代、弹性扩展的特点，使企业能够在不确定性下提升发展速度及抗风险能力，受到了越来越多的关注。当前，云服务商纷纷试水微服务产品，最为典型的，当属推出轻舟微服务平台、剑指整个微服务应用生命周期的网易云。 ...
摘要：刘超，网易云计算首席架构师，有多年的云计算架构与开发经历，积累了丰富的企业级应用的微服务化，容器化实战经验。近日，记者对刘超进行了采访，跟大家分享了微服务实战的挑战和一些常见的微服务误解，以及他对微服务发展趋势的判断。 刘超，网易云计算首席架构师，有10多年的云计算架构与开发经历，积累了丰富的企业级应用的微服务化，容器化实战经验。刘超将担任今年 5 月份 QCon 全球软件开发大会广州...
阅读 3280·2021-11-25 09:43
阅读 2083·2021-09-22 10:02
阅读 3309·2021-09-06 15:00
阅读 2297·2019-08-30 15:56
阅读 2346·2019-08-30 15:54
阅读 3223·2019-08-30 14:14
阅读 2257·2019-08-29 17:25
阅读 2901·2019-08-29 17:16
