0、前言
当一个公司有多个开发团队时，我们可能会遇到这样一些问题：
1.技术选项杂乱，大家各玩各
2.业务重复度高，各种通用api，登录注销，权限管理都需要重复实现（甚至一个团队都需要重复实现）
3.业务壁垒，业务之间的互通变得比较麻烦
4.部署方式复杂，多个域名（或IP地址）访问，给用户造成较大的记忆难度
5.多套系统，风格难以统一
6.等等...
当然，解决方式有不少。以下就来讲解下我们这边的一种解决方案。
1、思路
Angualr
Angular（注：非AngularJS） 是流行的前端 MVVM 框架之一，配合 TypeScript，非常适合用来做后台管理系统。由于我们曾今的一套 Angularjs 开发框架，我们继续选择 Angular 来进行实现，并尽可能的兼容 AngularJS 的模块。
SPA
选 SPA 还是多页？多余 Mvvm 来说，多页并不是标配。而且多页开发中，我们势必会关注更多的内容，包括通用header，footer，而不仅仅是页面的核心内容。
模块化
为什么要模块化呢？当有多个团队开发时（或者项目较大时），我们希望各个团队开发出来的东西都是 模块（不仅限于JS模块），这样可以让我们独立发布、更新、删除模块，也能让我们的关注点集中在特定模块下，提高开发效率和可维护性。
平台化
我们需要有一个运行平台（Website站点），允许在里面运行指定的模块。这样就可以实现单一入口，也容易实现通用逻辑，模块共享机制等等。
兼容 AngularJS 模块
在考虑将框架切换到 Angular 时，我们无可避免的会遇到如何兼容当前已有模块的问题。大致可选的方案如下：
1.参考 AngualrJS -> Angular 官方升级指南，一步步将模块切换为 Angular 的实现。（工作量大，需要开发团队调整很多东西）
2.iframe嵌入，会有一定的体验差异，但对开发团队来说，基本无缝升级，也不需要做什么改动。（无疑，我们选择了这套方案）
模块打包
我们需要将单个的模块打包为资源包，进行更新。这样才能做到模块独立发布，及时生效。
CSS冲突
在大型 SPA 中，CSS冲突是很大的一个问题。我们期望通过技术手段，能够根据当前使用的模块，加载和卸载CSS。
跨页面共享数据
由于涉及到iframe兼容旧有模块，我们无可避免，需要考虑跨窗口的页面共享。
公共模块
当一个团队的模块较多时，就会有一些公共的东西被抽取出来，这个过程，框架是无法知道的，所以这个时候，我们就需要考虑支持公共模块。（模块之间也有依赖关系）