|
优化范畴 |
二级功能点 |
问题描述 |
方案描述 |
方案负责人 |
实现难度 |
重要程度 |
优先级 |
|
进度 |
|
目前通过F5进行负载，F5实现了负载、压缩、长连接、页面缓存、健康检查等 |
|||||||||
|
负载 |
访问频次控制 |
如果调用者对我方系统某一接口进行高并发调用，可能直接导致系统所有接口均不能使用 |
实现方案有两种，方案一：在负载层限制，方案二：在访问控制层限制 |
|
|
|
|
|
|
|
雪崩问题防止 |
在集群环境中，某台机器压力过大或缓存被穿透或缓存故障，导致系统宕机，压力分流入其系统，引起依次宕机 |
实现方案有两个，方案一：流量限制，方案二：缓存防穿透 |
|
|
|
|
|
|
|
|
服务治理 |
主要是对服务的治理，包括注册、调用、集群中单体的降级、访问的快速熔断和访问限流 |
方案建议使用公司的ESG(Enterprise service governance)是指企业服务治理平台 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目前的访问控制层，主要实现了：UM权限校验、Session关闭、异常拦截 |
|||||||||
|
访问控制层 |
UM权限 |
对调用者进行身份验证，目前实现了身份的验证，没有实现身份和授权接口的关系认证 |
方案建议后续增加此类控制 |
|
|
|
|
|
|
|
Session管理 |
不使用Session |
目前已实现 |
|
|
|
|
|
|
|
|
异常管理 |
对外部调用者屏蔽异常信息，对内部调用者暴露异常信息 |
目前已基本实现，暂不提出改进方案 |
|
|
|
|
|
|
|
|
访问白名单控制 |
即使仅对调用者开通了部分接口（比如统一身份的接口），但它可以调用我们所有的接口 |
根据模块或者接口进行访问权限控制 |
|
|
|
|
|
|
|
|
访问频次控制 |
参照负载层的描述 |
不建议在这里控制 |
|
|
|
|
|
|
|
|
加解密 |
对部分敏感信息，加密之后才允许在网络传输 |
建议参考目前使用的对称加密处理 |
|
|
|
|
|
|
|
|
削峰控制 |
参照访问频次控制 |
不建议在这里控制 |
|
|
|
|
|
|
|
|
日志ID派号器 |
所有的请求，在日记中采用 |
目前已基本实现，暂不提出改进方案 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目前的聚合层，用于协调内部和外部服务，主要实现了：统一入口、服务聚合 |
|
|
|||||||
|
聚合层 |
统一入口 |
统一的访问入口，可以防止将内部实现对外部暴露，包括：服务定义、传输对象，通讯协议 |
目前已基本实现，暂不提出改进方案 |
|
|
|
|
|
|
|
服务聚合 |
聚合内部各个模块的实现，方便对外提供服务，建议考虑，后续是否进行多版本兼容。 |
目前实现基本满足需要，暂不提出改进方案 |
|
|
|
|
|
|
|
|
热点一级缓存 |
对于多读少写类业务（比如：秒杀、活动等），热点数据如果缺少缓存，则每次访问DB，对DB压力较大 |
方案建议使用分布式缓存Redis，并且Redis本身是集群环境 |
|
|
|
|
|
|
|
|
分布一致性 |
根据业务不同，区分强一致性和弱一致性业务 |
对于强一致性业务，要求实时重试和回滚； |
|
|
|
|
|
|
|
|
接口平滑升级 |
存在多个调用者调用某一接口，但是，接口升级时，调用方不能同时升级。 |
实现方案有两个，方案一：强制所有调用方和被调用方同步升级。方案二：采用版本号控制，允许设定时间段内调用旧版本接口 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目前的业务层，主要实现了：统一身份、统一权益等 |
|
|
|||||||
|
业务层 |
幂等性 |
以统一权益为例，当某个消费请求第一次发出时，消费后返回处理成功；第二次再发出时，却返回处理失败，或再次消费后返回成功。此时用户权益可能被重复减扣。 |
实现方案有两个，方案一：每个修改类请求增加一个流水号；方案二：根据业务主键判断是否是同一次消费。 |
|
|
|
|
|
|
|
热点二级缓存 |
公共业务数据，极少发生变化 |
实现方案有两个，方案一：通过分布式缓存Redis；方案二：通过本地缓存。 |
|
|
|
|
|
|
|
|
验证码派号器 |
验证码的生成，有统一的本地服务提供，统一解决安全、效率问题。 |
目前已基本实现，暂不提出改进方案 |
|
|
|
|
|
|
|
|
业务Code派号器 |
各个业务的编码Code，由统一的派号器生成，统一解决安全、效率问题。 |
参考验证码的生成。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
目前规约部分，目前已经完成规约包括：JAVA代码、DB代码、工程、接口、日志等规约。 |
|||||||||
|
规约部分· |
JAVA代码规约 |
JAVA代码的命名规约、编码格式规约 |
目前已基本实现，暂不提出改进方案 |
|
|
|
|
|
|
|
DB代码规约 |
DB代码的写法规约、安全规约 |
目前已基本实现，暂不提出改进方案 |
|
|
|
|
|
|
|
|
工程规约 |
工程的各层边界，规范、命名 |
目前已基本实现，暂不提出改进方案 |
|
|
|
|
|
|
|
|
接口规约 |
接口的鉴权、命名、通信、调用规约 |
目前已基本实现，暂不提出改进方案 |
|
|
|
|
|
|
|
|
日志规约 |
日志的格式、文件命名、查询规约 |
目前已基本实现，暂不提出改进方案 |
|
|
|
|
|
|
|
|
缩略词规约 |
同样的业务意义，只存在一种中英文名称 |
方案建议由业务书写其相关内容。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
综合部分 |
配置中心 |
用于管理各个模块，各个版本的配置项内容 |
实现方案建议通过ETCD缓存或者DB保存配置，系统启动加载配置，并且定时更新配置 |
|
|
|
|
|
|
|
服务熔断 |
如果依赖系统故障，则在调用其接口时，可能会引起我方系统资源长时间被占用，从而导致我方系统故障 |
实现方案建议有两个，方案一：由负载层控制调用时长；方案二：由业务代码控制实现调用时长 |
|
|
|
|
|
|
|
|
多级缓存 |
参见一级和二级热点缓存 |
根据数据的作用范围和热点情况，分级实现缓存 |
|
|
|
|
|
|
|
|
消息队列 |
业务处理由同步转为异步，或者系统间解耦时，需要消息队列介入 |
实现方案建议调研公司的消息中间件。 |
|
|
|
|
|
|
|
|
缓存的数据一致性 |
缓存中数据发生变化时，对应DB的同步更新方式。 |
实现方案有两个，方案一：由业务同时更新缓存和DB；方案二：由业务更新DB，而由定时Job更新缓存。 |
|
|
|
|
|
|
|
|
缓存穿透 |
缓存设置有效期后，如果缓存失效时间点，存在大量请求，则请求被导入后端DB，造成DB瞬间压力突增。 |
实现方案，缓存失效时，所有并发请求中，只允许有一个访问到DB，请求成功后更新缓存，再由其他请求读取缓存 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
应用灾备 |
异地灾备 |
核心系统建议具备异地容灾，防止单机房宕机或网络故障 |
依赖公司容灾系统可靠性 |
|
|
|
|
|
|
|
数据灾备 |
异地灾备 |
核心系统建议具备异地容灾，防止单机房宕机或网络故障 |
依赖公司容灾系统数据同步机制的可靠性 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|