中国移动骨干网全国架构中国移动架构大调整

转载

mob64ca140ee96c 2023-09-30 13:46:45

背景

最近移动前端架构升级，总结一下我们做了哪些改变。框架的事情越说越抽象，很难像show me the code 那样直观，除非你也在做类似的事情，否则很难觉得有所收获。每个公司的组织架构都不尽相同何况是给挑剔的程序员用的框架呢。所以说框架必然是要不断更新，不断优化调整之后才能适应这家公司。

其实新老更迭本身就会带来很多挑战。看似稳定的一切其实都是可以被替代的，目前的存在只是现阶段的妥协。

如果公司没有自己的docker化平台,那上线要做的事情就是同步。把需要上线的代码同步到服务器上。我们是基于jenkins做自动化部署。主要有两方面的改造，

明确开发&发版流程我们主要使用ESLint和StyleLint做强制代码check，git commit hook强制描述规则，文档描述使用markdown git分支规范（gitflow） Commit描述核心模块CodeReview（人工）
配合运维搭建自动化构建输出统一目录使用缩写做统一nginx配置

if ($uri ~ /hybird/(.*)/.*) {
      set $hybird /hybird/$1;
    }
    location ~ /hybird/(.*)/.* {
  }
复制代码

前端框架
除了要解决老系统的问题，我们还需要做到安全、解耦、可监控、可度量、可以快速发版、组件化、高性能、模块化、可扩展、热修复、一致性、隔离发版、BU化支持……
团队大多推崇vue，整个技术栈切换到了vue、webpack、Postcss…的技术体系。
使用选型后的技术体系，如何基于这样的技术选型设计一套能支撑3年（前端的平均寿命周期可能比这个还要低）的框架呢？首先这个框架必须进行合理的粒度拆解，必须能轻松的支持纵向功能级分层，横向按照BU分业务线。
为了提高复用性，按照UI组件、BC组件、页面、模块、前端服务按照不同粒度层次进行组合。
粒度化

一个大的系统，无论从功能层级角度、还是从业务角度、都应该能灵活的进行纵横拆解。一个系统应该可以分为独立的系统、系统中的标准流程、流程中的模块、模块中的组件、组件中的元素…，这些不同大小粒度代表了不同层级的复用性。