前言
目前负责的B端履约流程是整个B端最核心的应用，牵涉的上游会包括订单、交易、供应链、C端等；而整个履约流程会包括预约、排队、施工等多个节点；下游则会影响到结算、客户管理、门店经营等。所以如何保证系统稳定，并且支持业务扩展是目前需要去思考和解决的。
业务现状
主体使用端有四个、核心端是两个，对应于C端与B端。
- C端主要是履约流程的发起，使用者是用户。
- B端主要是履约整个流程的流转，使用者是技师。
承接业务场景：大方向上分四大类（到店、SAAS、上门以及其他），有部分业务流程是完全隔离开的，有部分复用。
系统现状
自从去年年底拆分服务之后，将整个履约流程先划分为领域层和聚合层，其中聚合层后面需要升级为调度层，将履约全流程从原先各业务独立维护、并深度耦合，向各服务独立、由履约层统一调度发展，由履约调度层完成全流程的流转。
数据层
- 履约数据目前还是在Sql Server统一集群上，同时公司约有一半业务数据也在集群上，及其容易发生连锁反应，导致系统不可用。
- 履约三张主表数据目前在8kw（26g）、16kw（35g）、58kw左右（92g），日增数据分别为10w、23w、60w左右。DB负载日益严重，慢sql查询日益增多，整体系统已经处于高危状态。
- 业务主表依然是以一张大宽表的方式（约50个字段）来记录业务数据，快照数据与流程数据耦合，表的职责定位不明确。
- 数据主要以sql server表做支持，不足以支撑所有业务的查询场景（模糊查询）与接口性能（C端接口999需要50ms）。
- 大量外部服务直连本领域表查询数据，影响领域化推进。
领域层
- 首先领域层是由原先服务拆分出来的，约有100个领域接口，功能职责不清晰，透出字段冗余，维护起来十分麻烦。
- 服务大致情况：11台机器（4核8G），日均QPS约为700（峰值约2000），平响10ms。
- 信安团队潜在敏感信息透出问题。
聚合层
- B端系统业务流程复杂不再赘述，并且耦合度及其高，导致在新增业务流程时需要在原有系统上做大的兼容，风险不可控。（这里规划调度层解耦开各个业务，还需要细细思考）。
- 现有B端系统中到店关联上下游最为紧密，对于核心接口的依赖降级严重缺失。
- 目前核心接口近50，非核心接口近200，其中很多接口性能平响过100ms、999线过500ms，这是严重不达标的，需要治理。
- 履约与施工流程的强耦合需要等施工检查域拆分后开始推进解耦。履约与订单域的耦合关系，以及订单域对到店产生的风险需要评估。
- 与其他领域的耦合，以及.net接口升级都是需要在考虑范围之内。
- 服务详情：14台机器（8核8G），日均QPS约为600（峰值约为1500），平响50ms。
领域化目标
2022整体目标是保稳定（慢sql优化，依赖降级，核心接口压测与优化），迁数据（数据迁移（mysql（分库分表），es，redis），直连解耦），领域化（包括依赖他人与被依赖）。另外还有还需要完成全链路密文计划。
估摸只能推动前两项和全链路密文，先加油吧！