我们团队之前发布过一篇文章，介绍了古茗前端到底在做什么，当然这只包含了我们团队内做的一部分事情。以端侧来划分，主要包括：中后台 web 端、H5 端、4 端小程序、Electron PC 端、Android/Flutter 客户端，我们需要为这些端侧方向做一些通用能力的解决方案，同时也需要深入每个端侧细分领域做它们特有的技术沉淀。本文主要介绍古茗在中后台技术方向的一些思考和技术沉淀。
古茗目前有大量的中后台业务诉求，包括：权限系统、会员系统、商品中心、拓展系统、营运系统、财务系统、门店系统、供应链系统等多个子系统，服务于内部产品、技术、运营，及外部加盟商等用户群体，这些子系统分别由不同业务线的同学负责开发和维护，而这些子系统还没有系统性的技术沉淀。随着业务体量和业务复杂度的不断增大，在“降本增效”的大背景下，如何保证业务快速且高质量交付是我们面临的技术挑战。
如上述技术演进路线图所示，我们的中后台技术架构大致经历了 4 个阶段：当业务起步时，我们很自然的使用了单应用开发模式；当业务发展到一定的体量，多人协同开发变得困难时，我们拆分了多个子系统维护，并使用了 systemjs 来加载子系统资源（微前端模式的雏形）；当遇到有三方库的多版本隔离诉求时，我们又引入了 qiankun 微前端框架来隔离多个子系统，保证各子系统间互不影响；那是什么原因让我们放弃 qiankun，转向完全自研的一套中后台解决方案？
其实准确来说，qiankun 并不能算是一个完整的中后台解决方案，而是一个微前端框架，它在整个技术体系里面只充当子应用管理的角色。我们在技术演进过程中使用了 qiankun 尝试解决子应用的隔离问题，但同时也带来了一些新的问题：某些场景跳转路由后视图无反应；某些三方库集成进来后导致奇怪的 bug...。同时，还存在一些问题无法使用 qiankun 解决，如：子应用入口配置、样式隔离、运维部署、路由冲突、规范混乱、要求资源必须跨域等。
我们重新思考了古茗中后台技术探索方向是什么，也就是中后台技术架构到底要解决什么问题，并确定了当下的 2 大方向：研发效率、用户体验。由此我们推导出了中后台技术探索要做的第一件事情是“统一”，这也为我们整个架构的基础设计确立了方向。
我们的整体架构是围绕着“统一”和“规范” 2 大原则来设计，目标是提升整个团队的研发效能。我们认为好的架构应该是边界清晰的，而不是一味的往上面堆功能，所以我们思考更多的是，如果没有这个功能，能否把这件事情做好。
我老板曾说过一个好的（技术）产品要做的第一件事就是取个“好”名字。我们给这套中后台架构方案取名叫「Mars」，将相关的 NPM 包、组件库、SDK、甚至部署路径都使用 mars 关键字来命名，将这个产品名字深入人心，形成团队内共同的产品认知。这样的好处是可以加强团队对这套技术方案的认同感，以及减少沟通负担，大家一提到 mars，就都知道在说哪一件事。
正如上述大图所示，我们是基于微前端的思路做的应用框架设计，所以与市面上大多数的微前端框架的设计思路、分层结构大同小异。这里还是稍微介绍一下整个流程：当用户访问网站时，首先经过网关层，请求到基座应用的资源并渲染基础布局和菜单，当监听路由变化时，加载并渲染路由关联的子应用及页面。