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

服务化的出现

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

最初是一个简单的类似的 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），期间继续不停的进行健康巡查，发现服务可用，则修改状态为服可用。
发现服务不可用的时候，直接抛出异常，不在阻塞等待。
三方都添加了报警，如果服务不可用，都会收到报警。

服务提供方的变动

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协议也由我们服务治理还给大家指定吧。

就写到这了吧！

揭开她的神秘面纱 - 零基础构建自己的服务治理框架

服务治理深入浅出（1）- 服务治理出现的必要性探索相关推荐

微服务治理实践：服务查询
来自:阿里巴巴中间件本文是<微服务治理实践>系列篇的第二篇文章,为大家介绍如何实现服务查询.该系列文章基于阿里云商业化产品 EDAS 的微服务实践,如果你的团队具备较强的微服务治理能力, ...
微服务该如何进行服务治理？
作者:李秉谦董添 || 网易乐得技术团队来自:http://tech.lede.com/ 1. Spring Cloud Netflix的优势对于微服务的治理而言,核心就是服务的注册和发现.所以 ...
一文读懂 Spring Boot、微服务架构和大数据治理三者之间的故事
微服务架构微服务的诞生并非偶然,它是在互联网高速发展,技术日新月异的变化以及传统架构无法适应快速变化等多重因素的推动下诞生的产物.互联网时代的产品通常有两类特点:需求变化快和用户群体庞大,在这种情况 ...
RocketMQ 千锤百炼--哈啰在分布式消息治理和微服务治理中的实践
作者|梁勇背景哈啰已进化为包括两轮出行(哈啰单车.哈啰助力车.哈啰电动车.小哈换电).四轮出行(哈啰顺风车.全网叫车.哈啰打车)等的综合化移动出行平台,并向酒店.到店团购等众多本地生活化生 ...
哈啰在分布式消息治理和微服务治理中的实践
简介:随着公司业务的不断发展,流量也在不断增长.我们发现生产中的一些重大事故,往往是被突发的流量冲跨的,对流量的治理和防护,保障系统高可用就尤为重要. 作者|梁勇背景哈啰已进化为包括两轮出 ...
微服务治理实践：服务契约
简介:随着微服务架构越来越流行,越来越多的公司使用微服务框架进行开发.甚至不止是公司,连笔者的研究生导师都要对实验室的Spring Boot工程项目转型使用微服务框架了. 本文是<微服务治理实践 ...
SpringCloud微服务架构,Spring Cloud 服务治理(Eureka,Consul,Nacos),Ribbon 客户端负载均衡,RestTemplate与OpenFeign实现远程调用
什么是SpringCloud 微服务架构 • "微服务"一词源于 Martin Fowler的名为 Microservices的博文,可以在他的官方博客上找到 http://mar ...
架构专家梁勇：哈啰在分布式消息治理和微服务治理中的实践
背景介绍哈啰已进化为包括两轮出行(哈啰单车.哈啰助力车.哈啰电动车.小哈换电).四轮出行(哈啰顺风车.全网叫车.哈啰打车)等的综合化移动出行平台,并向酒店.到店团购等众多本地生活化生态探索. 随着公 ...
一文透析 Spring Boot、微服务架构和大数据治理三者之间的故事
微服务架构微服务的诞生并非偶然,它是在互联网高速发展,技术日新月异的变化以及传统架构无法适应快速变化等多重因素的推动下诞生的产物.互联网时代的产品通常有两类特点:需求变化快和用户群体庞大,在这种情况 ...

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

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

服务化的出现

灾难的发生

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

服务提供方的变动

开会开会提出服务治理

服务治理的完善

揭开她的神秘面纱 - 零基础构建自己的服务治理框架

服务治理深入浅出（1）- 服务治理出现的必要性探索相关推荐

最新文章

热门文章

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

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

服务化的出现

灾难的发生

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

服务提供方的变动

开会开会 提出服务治理

服务治理的完善

揭开她的神秘面纱 - 零基础构建自己的服务治理框架

服务治理深入浅出（1）- 服务治理出现的必要性探索相关推荐

最新文章

热门文章

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

开会开会提出服务治理