微应用架构开发演进

913 阅读3分钟

概述

做技术来讲,想要深入的话,都会走到架构这一关,这次拿一个真实的需求来讲架构演进,主要分享下在做架构时的一些关注点和思路。

先看下最终实现的结果:

微应用阶段结果.jpg

下面开始讲解从开始到实现结果的过程。

不管做架构还是做业务,整理清楚需求都是第一步。

需求和目标整理

找相关的产品和ued来确定想要达成的效果,整理的结果如下:

  • 主应用支持多个子应用项目接入,新项目还没开始开发。
  • 主应用和接入应用支持独立git和独立发版,互不影响。
  • 主应用需要和子应用使用同样的组件库,维持统一交互。
  • 子应用主需要关注业务开发,即:能够保持和主应用同样交互的同时,后续主子应用架构升级无感知不影响业务。
  • 业务方2周后开始参与开发,需要在2周内搭建一个可以使用的架构,保证业务稳定开发。
  • 业务方4周后要求上线整体功能。

需求和目标确定了就要开始分析拆解架构任务了。

拆解架构任务

调研确定方案

  1. 寻找开源方案,对比方案优缺点,分析选择适合项目的方案。
  2. 学习开源方案文档,搭建简易demo。
  3. 开源组件引入项目,搭建业务简易demo。

搭建基础架构

  1. 搭建子应用架构,业务demo实现主应用同样的路由处理等架构。
  2. 定义主子应用数据交互规则,开源组件提供了基础的使用,需要制定规范。

公用资源拆分

  1. 确定主子应用可以公用组件库方案,子应用如何使用主应用的基础组件和业务组件?cdn?还是其他方案?需要确定。
  2. 后续会有其他子应用接入,需要把子应用非业务部分做抽离到内网组件库,抽离哪些配置?如何公用资源?如何调整主子应用打包?

投入资源和时间

  • 一个人力。
  • 目前手里还有些其他任务在做,想要两周内把架构搭建和相关方案都确定好风险是很大的。
  • 开始分阶段,以2周后业务可以参与开发为目标做拆分。

阶段计划

第一阶段

完成前2块任务,最终搞出一版可以让业务直接开发的架构,组件和基础配置可以先放子应用用着,不影响开发,后续再同步拆分公用部分。下面是第一阶段的结果图:

微应用阶段1.jpg

第二阶段

和子应用业务开发同时进行,确定抽离方案和开发 + 架构调优,业务开始用后会有不同问题暴露出来,收集并优化已有架构。

第三阶段

上线后测试调优。

然后就是按着拆解后的架构计划开搞了,每周复盘下内容,看是否会延期风险。

最终细节都开发完后,顺利上线,上线后调优就按着正常迭代处理了。

总结

目标。架构目标降本增效,这个是根本目标。

流程。架构演进要根据不同需求、需要的资源和时间、达成的不同效果来进行,但大致流程都是一样的。需求分析、确定资源和阶段开发时间、拆分架构计划、定期复盘查进度暴露风险。

服务于业务。架构是服务于业务的,需要保证业务稳定性。

主动推进。很多比较大的架构搭建涉及跨部门、跨技术栈,需要及时主动推进,保证顺利进行。

储备知识,拓展思维。多学习,多关注市场方案,积累大量的知识后,在最初的分析选择上会节省时间,少走些弯路。