概述
做技术来讲,想要深入的话,都会走到架构这一关,这次拿一个真实的需求来讲架构演进,主要分享下在做架构时的一些关注点和思路。
先看下最终实现的结果:
下面开始讲解从开始到实现结果的过程。
不管做架构还是做业务,整理清楚需求都是第一步。
需求和目标整理
找相关的产品和ued来确定想要达成的效果,整理的结果如下:
- 主应用支持多个子应用项目接入,新项目还没开始开发。
- 主应用和接入应用支持独立git和独立发版,互不影响。
- 主应用需要和子应用使用同样的组件库,维持统一交互。
- 子应用主需要关注业务开发,即:能够保持和主应用同样交互的同时,后续主子应用架构升级无感知不影响业务。
- 业务方2周后开始参与开发,需要在2周内搭建一个可以使用的架构,保证业务稳定开发。
- 业务方4周后要求上线整体功能。
需求和目标确定了就要开始分析拆解架构任务了。
拆解架构任务
调研确定方案
- 寻找开源方案,对比方案优缺点,分析选择适合项目的方案。
- 学习开源方案文档,搭建简易demo。
- 开源组件引入项目,搭建业务简易demo。
搭建基础架构
- 搭建子应用架构,业务demo实现主应用同样的路由处理等架构。
- 定义主子应用数据交互规则,开源组件提供了基础的使用,需要制定规范。
公用资源拆分
- 确定主子应用可以公用组件库方案,子应用如何使用主应用的基础组件和业务组件?cdn?还是其他方案?需要确定。
- 后续会有其他子应用接入,需要把子应用非业务部分做抽离到内网组件库,抽离哪些配置?如何公用资源?如何调整主子应用打包?
投入资源和时间
- 一个人力。
- 目前手里还有些其他任务在做,想要两周内把架构搭建和相关方案都确定好风险是很大的。
- 开始分阶段,以2周后业务可以参与开发为目标做拆分。
阶段计划
第一阶段
完成前2块任务,最终搞出一版可以让业务直接开发的架构,组件和基础配置可以先放子应用用着,不影响开发,后续再同步拆分公用部分。下面是第一阶段的结果图:
第二阶段
和子应用业务开发同时进行,确定抽离方案和开发 + 架构调优,业务开始用后会有不同问题暴露出来,收集并优化已有架构。
第三阶段
上线后测试调优。
然后就是按着拆解后的架构计划开搞了,每周复盘下内容,看是否会延期风险。
最终细节都开发完后,顺利上线,上线后调优就按着正常迭代处理了。
总结
目标。架构目标降本增效,这个是根本目标。
流程。架构演进要根据不同需求、需要的资源和时间、达成的不同效果来进行,但大致流程都是一样的。需求分析、确定资源和阶段开发时间、拆分架构计划、定期复盘查进度暴露风险。
服务于业务。架构是服务于业务的,需要保证业务稳定性。
主动推进。很多比较大的架构搭建涉及跨部门、跨技术栈,需要及时主动推进,保证顺利进行。
储备知识,拓展思维。多学习,多关注市场方案,积累大量的知识后,在最初的分析选择上会节省时间,少走些弯路。