业务架构思考
内容总结：主要是为了总结一些需要前沿探讨的一些内容设计
划分整体业务流程
拿售后投诉举例，整个流程分为 会员端发起 / 商家协商 / 平台介入
再用角色进行拆解时，整个业务可以分为基础能力【业务数据承载、流转】、会员端交互、平台小二交互
在面对多种业务类型承接时，通过业务类型标识区分不同大业务场景，比如投诉、举报等，对于业务场景中的小身份区别通过业务身份
对于业务类型大的场景通过业务隔离进行区分，而小的业务场景通过拓展点区分具体细节
设定动作流
确定关键节点
确定业务的关键节点，比如说 创建 / 协商 / 平台介入 / 判决/ 完结
在对应的关键节点上，设置对应可执行的动作活动
比如说创建节点毫无疑问动作是创建，协商里面是提供方案、拒绝方案
确定节点中行为
在有了这些业务的划分后，思考的是一个通用的动作里面需要有什么模板行为
拿创建、提供方案来说，都会涉及到入参的校验，或者动作节点检查之类，那么首先我们需要preCheck的校验逻辑
在前置校验通过后，可能不同业务场景对这个动作要求理解不同，举个例子比如普通商家人手少，需要的协商时间较长，而官营的人手多，协商时间可以适当减少，那么像这些参数组装，我们可以设计一个prepare进行承接内容
在具体业务参数准备好了，然后我们要做的是基础能力的建设，比如将创建的投诉数据落到数据库，这里需要execute
在执行完后可能会涉及一些其他系统的状态更新，我们可以在afterExecute中实现一些消息重试、幂等的逻辑进行状态的异步更新
总结下来我们会需要 precheck/prepare/execute/afterExecute等基础方法，像这些可以作为大的能力作为沉淀，并开放拓展点给到不同业务方进行实现
具体动作的拆分
在开拓展点的时候，就很考验对业务的理解，以及对未来的发展的一个前瞻规划性，拓展点方向大了，就会导致后续新业务接入进来，需要实现内容多，而且平台侧难以规划整体方向，而如果规划小了，又会导致拓展点频出，平台侧基本没有能力沉淀
比如说像会员端交互上，往往就是不同页面承载了不同的业务功能，那么对于不同页面可以视为不同活动
总结交互上面的大的方向，基本上也是precheck / prepare / render / afterRender
细分时，交互上可能不同端的处理不一样，可以设置renderForPC / ForH5的场景
在业务详情页时，涉及到业务详情渲染，可操作按钮列表等，像这些就可以按基本栏块进行拆解设置拓展点
数据驱动分析
在业务已经有基本的业务流程，需要进一步发展时，数据分析是一个很好的方法，结合BI等对这些数据进行分析
业务切分埋点
首先我们要对业务场景进行切分，然后针对这个场景划分需要埋点的数据场景
拿对耗时敏感的交互端业务来分析，对会员来说，敏感的点在于页面加载时长，交互操作时长
对于页面加载时长，在上文中分析过页面其实也可以抽象成一种能力，本质上也是分校验、准备数据、渲染具体内容等，那就可以在抽象页面类中，做埋点数据日志的登记
比如说，会员请求到页面接口时，开始计时，在precheck、prepare、render中记录对应的时间，并且将对应具体页面实现记录下来，以及对应的一些动作行为
数据分析场景
有了这个大方向的数据记录，通过日志的抓取清洗到数仓、实时日志分析中，我们就可以观察到具体是哪些页面耗时长，在页面中，我们是在precheck、prepare请求外部数据、还是render渲染页面中耗时较长，针对这些情况做具体分析
在到具体内容时，比如说页面的按钮交互，往往就是按钮下放了跳转链接or请求外部接口行为，对于跳转链接的行为可以让前端做统一按钮点击的数据埋点，而后端给前端返回按钮的时候，不单止要返回按钮名称、按钮内嵌的链接，还应该放置一些按钮唯一标识、以及如果有灰度业务的话，也可以在拓展属性中设置灰度标，这样子便于前端埋点的数据抽取给数仓能做进一步的分析
而请求外部接口的行为，可以通过aop切面的能力，将外部接口首先收拢到仓储层，在通过注解将调用外部接口的行为进行记录，记录请求时间start、end、接口耗时、以及可能需要的输入输出结果、接口名称、接口描述、接口唯一标识等，在接口唯一标识中，我们也可以在做一些区分，比如说都是交互层请求的数据，可以带上 proxy:pageRender:queryXXX 在日志切分时，就可以通过proxy、pageRender切分出对应的业务进行分析查询
除了耗时外，我们也可以通过在抽象层进行捕获异常，将异常信息进行记录，标记具体页面、具体动作点异常类型，后面基于这些异常的数据分析，也可以作为日常的监控持续维护系统的健康和运营