做网站需要的注意事项,企业官网建设的重要性,拟定一个物流网站的建设方案,怎么做的英文网站本系列用大白话#xff0c;手把手带你实现上百个BAT公司内部真实的常用中型系统。评论抽奖送书 与培训班/营销号/忽悠人的低水平作者#xff0c;不同的是#xff1a;
保证听懂#xff08;小白也可以#xff0c;这是我的一贯风格#xff0c;字典式小白式的输出#xff0… 本系列用大白话手把手带你实现上百个BAT公司内部真实的常用中型系统。评论抽奖送书 与培训班/营销号/忽悠人的低水平作者不同的是
保证听懂小白也可以这是我的一贯风格字典式小白式的输出大家容易交流
绝对真实保证业内调查过、BAT级别公司实现过有的作者异想天开的自嗨能看到一堆漏洞
欢迎讨论你进步我也进步最好怼死我让我知道我是井底之蛙 什么你问我为啥只写中型系统不写大型系统第一我自己还没玩明白呢就不误人子弟了。第二、大系统敏感信息很难完全清干净怕被告。第三、能真正看懂的人也少。
一、背景 引子是让你明白本文可以作为供应商/合作方管理系统的实现你也可以应用在其他系统中。 首先读者应该明白现如今独自一套系统就能服务于用户的情况很少大多都要请求本系统外的其它系统这些系统可能是内部的或是外部的大家互相交互才形成了可以服务于真正用户的互联网功能我随便举几个例子
1腾讯视频做的开通腾讯会员任意合作方会员的组合需要和多个合作方酷狗、酷我、体育的系统进行交互。 2腾讯自选股或者任何买卖股票的app他可能自己卖股票吗不可能的内部对接了不知多少券商业内一般称为“上游”即实际提供服务方 3支付宝/微信充话费是支付宝自己能操作你手机号里的钱吗不是是支付宝对接了移动联通电信三大运营商包括全国总公司、省级分公司、市级供货商等等
这也引出了一个问题你内部系统的服务质量基本依赖于你的对接方系统质量。
比如我们内部系统做的特别好0.01秒就为用户做好了一切工作有用吗并没有因为真正提供服务的是你的合作方上文提到的炒股app对券商、支付宝充话费对中国移动以下统称为合作方如果合作方的系统特别烂买个股票永远成交失败冲个话费三天才到账你的系统再好也没有。 二、需求分析
基于上文提到的背景大部分公司都会有这么一种诉求健康度系统它可以识别外部系统的健康度并根据健康度控制流量。
说简单点就是你合作方系统老是办理失败那我就不让用户从你的系统办了否则降低收入不说因为成功率低我的用户还会骂我还是成功率低/耗时高。 三、目标明确
目标很明显只要我们知道某个合作方是不健康的就生成一条记录代表他被打入冷宫我们的系统查到记录就不会让用户访问它。
当然完全自动识别健康度是不可靠的毕竟是机器我们必须有人工介入的手段首先我们允许合作方主动通知我们系统不健康比如在维护升级、在调整东西、服务出问题、不在交易时间内等等我们得到这个消息就可以做相应的调整不让用户看到他家产品
目标一正确接收到合作方系统不健康的消息
其次也不能完全信合作方的操作我们系统内部也要有人为干预的手段方便我们管理。比如我们观察到某个合作方质量很差就手动给他标为不健康。如果我们和某个合作方挣钱很多就算质量差我们可能也会手动给他删除不健康记录。
目标二系统内部可以操作不健康消息增加/删除/修改/查询
保证两边人工操作没问题后我们再做自动识别
目标三系统自动识别不健康合作方并生成不健康记录
有心人看到这里肯定会问了你这不健康就永远不合作了永远打入冷宫了当然不是我们识别到健康度达标可能人家系统恢复了、优化了要继续让用户来这个合作方消费。
目标四系统自动识别健康度再次达标的合作方并删除不健康记录
至此我们的功能就算是说完了接下来分析一下我们的系统需要注意的问题 四、系统设计重点
大部分系统的重点一般在性能、可用性、安全三方面来说。
4.1 性能
因为考虑到每个用户请求进来都要获取各个合作方的健康度信息为了动态推荐商品之类的为了速度考虑最好所有信息都在某块内存redis可以直接查到。
所以我们最好将所有的数据生成工作提前做好这里包括但不限于
1获取合作方提供的健康度信息不可能每个用户请求都去请求合作方系统
2判断健康度需要的数据的获取包括是否连通、成功率、平均耗时、配置等
3健康状态的判断和灰度逻辑不可能每个用户请求来现场算是否健康
4健康状态信息缓存存redis加快读取速度
4.2 可用性
需要明白的是我们的系统始终是一个可旁路系统首先要考虑我们的系统挂了或者经常超时怎么办绝对不能影响主系统主流程的运行。
为了达到这个目的我们可能的策略包括但不限于
1某些降级策略如健康度功能不可用时根据配置的默认顺序来推荐合作方。
2可配置超时时间按时没运行完也要返回
其次我们要保证误判尽量的少保证最大的正确性为此我们可能的策略是 1合理的判定不健康算法、平滑的过渡方式
2判断健康的所有指标都可配置实现精细化运行根据具体合作方的实际情况配置。
4.3 安全
保证和外部交互健康度数据、内部存储健康度数据都是安全的。
和外部交互时签名加密
内部存储时签名 这里普及一些基本知识后续文章不会再提大家提到安全老是说签名和加密他们的作用是不同的。 签名主要功能是防篡改是无限集合真实内容向有限集合签名的映射根据签名是无法还原内容的接收方收到内容后按约定的算法和密钥算出签名和收到的签名一样就是没被篡改。 加密主要功能是防泄漏是无线集合向无限集合的映射因为陌生人即使拿到了整个消息依旧看不懂写的什么而接收方解密拿到明文可以进行处理。 至于签名和加密的算法的种类本系列也不会再科普可以自己上网搜一下。 五、方案设计概述
由于功能较多我们大概分两阶段实现
第一步先把合作方和本系统内部的人为干预手段做好并且搭起基本架构开始对外提供服务即其他服务可查询合作方是否健康了
第二步我们再把自动判定健康的数据获取、判定健康、根据健康度控制流量等功能补齐。
为了方便我们把代表某合作方不健康的一条记录称为“公告”
意思是我合作方发公告告诉所有关心的模块我不健康了
六、手动设计
为了方便理解方案一种可能的基本存储结构是这样的
6.1 db存储结构
create table xxtable
(Fid bigint not null auto_increment,F***_id varchar(64) not null default comment 供应商id,F***_id varchar(64) not null default comment 公告id,Fcreatetime DATETIME not null comment 公告创建时间,Fupdatetime DATETIME not null comment 公告更新时间,Fuserid varchar(64) not null default comment 操作用户id,Fbegintime DATETIME not null comment 公告开始时间,Fendtime DATETIME not null comment 公告结束时间,Fty int unsigned not null default 0 comment 类型0:运营商1:后台2:自动’,Fstatu int unsigned not null default 0 comment 状态 0:无效 1:生效中,Fchanged_count
);
当然这是基本字段有需要你再加。
ckv的区别是增加一个合作方公告开关
6.2 Ckv存储结构
//不健康信息
//供应商公告keykey: {ID:xxservice_gddianxin}//前缀供应商id //Boss后台配置的公告keykey: {ID: xxservice_gddianxin_boss}//前缀供应商id后缀value: [ { :gddianxin, //供应商id ID:123123123, //记录序列id begin:2020-7-2 00:00:00, //开始时间 end:2020-7-3 00:00:00, //结束时间 eff:true //是否生效部分供应商可能存在取消的情况 }] //公告开关key: //前缀供应商id后缀{ID:xxservice_gddianxin_flag } value:1(2)//1:打开2关闭
6.3 协议设计
和合作方交互的接口可能长这个样子
我方请求合作方
1. ?xml version1.0 encodingUTF-8?
2. req
3. timestamp1514736000/timestamp
4. signmsgXXX/signmsg
5. channelzhifubao/channel
6. /req合作方的返回解密后
1. ?xml version1.0 encodingUTF-8?
2. rtn
3. code0/code
4. msg同步成功/msg
5. channel0/channel
6. upgradeInfo
7. item
8. upgradeID UC-051-20200702-96038/upgradeID
9. upgradeContent系统故障/upgradeContent
10. beginTime2020-7-2 00:00:00/beginTime
11. endTime 2020-7-3 00:00:00/endTime
12. effectivetrue/effective
13. /item
14. item
15. upgradeID UC-051-20200703-96000/upgradeID
16. upgradeContent系统升级/upgradeContent
17. beginTime2020-7-3 00:00:00/beginTime
18. endTime 2020-7-4 00:00:00/endTime
19. effectivetrue/effective
20. /item
21. /upgradeInfo
22. /rtnCode是返回码upgradeInfo是公告列表含有多个公告主体。公告主体含有升级序列id、升级内容、开始时间、结束时间、生效标志等字段。注意如某公告被取消不应在运营商返回的报文中直接消失而是应将effective置为false 科普一种可能用到的通信时加密签名算法- sha256_HMAC作为签名的算法案例如下 第一步假若传入如下参数bank_typeWX;fee_type1bodyXXX 第二步按照参数key值进行字典排序(按照字段名的ASCII 码从小到大排序)并且使用””作为分隔符把参数串成字符串。bank_typeWXbodyXXXfee_type1 第三步用双方约好的密钥secret_key对组装的字符串进行加密signmsgsha256_HMAC_func(secret_key , bank_typeWXbodyXXXfee_type1)。 其它协议如我方服务的查询接口、定时任务接口、合作方主动推送接口请自行设计字段都非常简单不再说了。
定完协议我们可以看基本架构是什么样子 6.4 架构设计
在设计前我们再次明确之前提到的设计重点性能、可用性、安全忘了的同学翻上去看。
基于性能考虑我们需要读写分离读操作直接读redis节省时间。
基于可用性考虑我们的定时任务链路和查询都需要层层注意。
基于安全考虑信息的安全和服务本身的安全我们的外部交互协议和运营后台很重要。
基于这些考虑设计是这样的 介绍一下模块
定时任务负责定时触发查询
运营商接入服务负责调取运营商接口向上屏蔽运营商接口的不一致性对内提供标准接口。同时方便做一些安全的校验。
公告服务提供核心的查询和写入功能。
了解模块后详细解释一下三条链路的策略
性能读redis很快就不说了主要是挑战1可用挑战2安全
首先看定时任务链路左方蓝线
1定时任务请求获取公告接口。它应部署在多台脚本机如果其中一台出现问题其它机器依然正常工作。万一真的都挂了就要触发监控和报警通过微信或电话直接提示负责人尽快解决问题。
2链路往下走获取公告接口负责调用运营商接入服务获取信息并写入redis。
3而运营商接入服务负责调取运营商接口向上按标准参数返回。由于查询的无状态可以多机部署某台机器挂了可以自动切量。 总体看一下这条链路各模块有自己的机制保证可用性如果确实整条链路失效了公告信息就会暂停更新不会造成更坏的影响。 然后看查询主链路中间红线
1和其他服务交互部分请求查询公告接口。如果请求异常会有降级策略返回系统未维护。另外由于查询是无状态的多机部署采用类cl5的策略保证可用性。
2链路往下走查询公告接口它会查询公告信息redis然后返回结果。这里对查询结果的各种情况的处理就非常关键。
对于明确成功的结果就正常返回。对于超时、明确失败、未知情况都会有降级策略返回运营商未维护。其中对于超时情况笔者设置了超时时间为50ms保证主链路不会耗时过长。 笔者解决了第一个挑战再看第二个挑战 是由运营后台链路右方黑线加入了人工干预手段保证了系统故障时有人为干涉的兜底策略。
总体看笔者的系统除了redis其他地方都是无状态的所以可以多机部署任何机器出现问题都会有其他机器保证可用。而对于redis笔者有查询降级策略和设置超时时间即使挂了也不影响主链路。所以总体来说笔者解决了上面提到的两个挑战。 七、自动设计
刚才我们实现了人工干预手段和公告服务的基本框架接下来我们完善自动健康度的功能。
那么一个健康度系统的第一步就是如何判定不健康。
7.1 准备需要的信息
我们需要读到成功率、耗时、探测等数据考虑到不能因为新系统需要的操作就影响老流程我们必须做成异步写的下面我列举几种可能的方法
7.1.1 其他服务写redis
数据是由redis存储的记录分钟内请求成功失败数量最后一次请求是否成功下面是某示例
Key 供应商_id 接口 时间 req_num
key: Gmccactive_order_202010101500_req_num
value: 22
key: Gmccactive_order_202010101500_succ_num
value: 50
keyGmccactive_last_req
value: 1
当然写操作可以自己决定一下是否异步。
可以自己实现异步也可以同步毕竟写redis操作还是挺快的
7.1.2 其他服务生产消息
让其他服务放一个消息在消息队列里rabbitmq、kafka等里面有本次请求成功失败和耗时公告服务来消费即可。
7.1.3 公告服务读DB
一般情况下其它系统都会有订单DB、请求流水DB、日志DB等等如果评估可以使用就不需要别的服务上报配置脚本去捞DB信息即可。
7.1.4 建议
一般情况下我建议你方法1和方法2中选择方法1毕竟一个redis物尽其用没必要引入消息队列
剩下这两种方案各有利弊实时上报单次计算成功率的耗时更少但是需要暂存下单数据会影响下单流程。而拉流水不用暂存数据也不会影响下单流程但是单次计算成功率耗时会多一些包括了拉取流水和计算。
7.2 判定不健康 挂起公告实例图
1探测、多维度检测实时成功率、耗时进行判断。
2大概的代码逻辑应该是这样
if 探测失败次数高于阈值挂起公告
if 请求量大于阈值 and (成功率低于某阈值 or 耗时高于某阈值挂起公告。 这两方面分别保证的系统正常ping通就可以和业务正常具体成功率耗时达标。 7.3 如何探测 7.3.1 类CL5健康度方案 类CL5健康度方案图
每隔1个周期ping探测运营商接口联通性如果ping成功则开始放量真实量统计周期内失败数量与失败率如果高于阈值时按照一定比例开始恢复。
单机方案在此场景不可用因为Ping 探测接口连通性不能解决业务错误问题。
7.3.2 全局灰度方案 全局灰度方案图
由健康度服务进行选择灰度放量进行真实量探测。当成功量上升时灰度比例增大到直接放开当成功率下降时灰度比例下降延长时间。
经评估缺点如下损失业务真实量、开发成本较高、量级波动大时成功率变化时会出现反复较少放大比例的问题。
7.3.3 重放线上真实量 图3-8 重放线上真实量图
获取线上真实请求周期内进行n次重试,计算成功率连续m个周期内成功率达标后放开公告。优点是用户无感知实时性高但是如果用户未黑名单用户可能会误以为系统异常。
对于重放的接口有多种选择重放办理接口和重放查询接口的选择只能是重放查询接口因为部分运营商不支持幂等重复办理风险。就是存在一人重复办理多笔单的风险但只是查询商品就无所谓。
既然恢复可以用重放探测笔者提出一个假设一直重放仅按照重放的量来计算如何挂公告。因为部分运营商在办理成功后下次查询就会失败。而且对于量小的运营商重放量可能大于正常量。因此不适合只用重放量来计算健康度。
提示因为考虑法律问题我们没有权利替用户发起任何请求请求包括查询商品请求所以方案三一般不考虑。
7.3.4 总结
如果不考虑方案三的话可能比较优秀的做法就是方案1方案2结合起来看稍作修改即可。
方案2的缺点正好可以被方案1弥补我们先做探测如果达标再进行方案2的灰度。
大概的流程粗略看可能是这样 7.4 完成设计
有了大概思路我们应该把所有的想法用公式和图表示出来 关于更具体的代码我希望你能自己写出来我在这里提供一种简单的方法你可以把心里的详细状态扭转全部画出来然后转化成表格形式我们剩下的工作就这是看着表格写代码而已非常方便。只是自动机的一点用法acm大佬可忽略 小提示如果对这种思想比较感兴趣我想你一定做过leetcode第八题字符串转换整数 (atoi)可以看看这个题解来入门这种思想题解 八、总结和QA
8.1 全局架构图 8.2 为何让其他服务直接操作redis
刚说了不使用消息队列是因为嫌麻烦。
同时其他服务也不是直接操作redis它们也并不知道怎么操作。肯定是公告服务提供的接口呀。图中没画了 8.3 说为了安全要加密外部交互信息但文中协议没有
是为了让读者理解协议是解密之后的明文。
8.4 看完还是一脸懵不会写
实在有需要可以找我我可能会给你时序图之类的资料但是代码不可以。
8.5 为何必须有redis缓存我想结构简单一点
如果你想服务内本地缓存也可以只是缓存命中率会比较低因为真实环境动辄几十上百个进程。
