当前位置: 首页 > 后端技术 > PHP

服务治理浅显易懂(一)-服务治理必要性探索

时间:2023-03-29 21:06:45 PHP

以下内容是我自己的理解,不保证正确,可能是对的,也可能把你引到沟里,通过判断你自己。更多详情,请观看直播揭开她的神秘面纱——零基础搭建属于你自己的服务治理框架因为一些原因,我们在服务,我们公司研发了一套服务治理框架。当时老虎吓了一跳,赶紧在手机上记下关键词:“面向服务”、“服务治理”、“服务治理框架”。回去后,我立即寻找。感觉很高级,但是不明白为什么要面向服务。什么是服务治理?很多文章一上来就直接说他们的服务治理很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...