以下内容都是自己的理解,不保证正确,可能是对的,也可能把你带沟里,自己甄别。

很久之前听别人分享他们的架构,总会说,因为某某原因,我们进行服务化,我们公司开发了一套服务治理框架。

当时虎躯为之一震,感觉在手机上记下关键词:“服务化”、“服务治理”、“服务治理框架”。
回去之后马上搜索,觉得很高大上,弄不懂,为什么要服务化,到底什么是服务治理啊?
很多文章一上来就直接讲他们的服务治理多 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协议也由我们服务治理还给大家指定吧。

就写到这了吧!

还没听够,老铁周三有场直播,欢迎咱们接着聊:PHP 进阶之路 - 亿级 pv 网站架构的技术细节与套路

如果觉得我的文章对你有用,请随意赞赏
已赞赏

你可能感兴趣的文章

本作品 保留所有权利 。未获得许可人许可前,不允许他人复制、发行、展览和表演作品。不允许他人基于该作品创作演绎作品 。

13 条评论
vericmore · 4 天前

zookeeper etcd

+2 回复

wujunze · 5 天前

老铁 就服你 涨姿势了

回复

0

谢谢老铁!

周梦康 作者 · 5 天前
0

居然打赏,老铁稳。

周梦康 作者 · 5 天前
火蜥蜴 · 4 天前

虽然还是没啥感觉?

回复

0

啊!!!!!编了这么长的故事,还是没感觉,好吧~~~~就是把共性化的问题抽出来,单独成为一个模块,就和大家平常优化代码一个道理。

周梦康 作者 · 4 天前
0

老铁太打击我了~~

周梦康 作者 · 4 天前
0

@周梦康 但是文章讲的很好,很详实

火蜥蜴 · 4 天前
nomico · 4 天前

懂了(此处应有表情)~

回复

0

有帮助应该打赏,哈哈哈哈

周梦康 作者 · 4 天前
子遥遥遥 · 2 天前

对于于我们lnmp架构的web网站
服务注册中心 就等于是一个DNS或者是负载均衡器
然后php-fpm 就等于是一个服务提供者
浏览器客户端 就是服务消费者
这样理解对吗?

回复

0

有一些相通的地方。

周梦康 作者 · 2 天前
载入中...
周梦康 周梦康

1.5k 声望

发布于专栏

周梦康

💖💖💖 PHP 老司机

18 人关注