之前在360的时候做过一套完整的方案就是通过cordova做为壳来达到多端融合的方案，能力延伸到客户端整个面上，主要关注2个方面体验和效率。
在众荟更加关注技术在业务快速发展中，持续高效的做下去，所以需要考虑产品和技术的结合。
众荟这面的产品漏斗是通过市场需求量来划分的，越上层的产品专业度越低，相对应的人群也更大，我负责的2条产品线其实也这样的划分标准。下面是个示意，公司的漏斗比这个多。
每一层对应的一个产品用来占领这块的用户，并且上层的用户会由于市场层面的教育逐渐的漏到下层，下层的用户也会结合上层的产品来使用（毕竟是收费型产品），所以从业务层面来看整体的架构要关注2个方向：
- 数据和部分逻辑要抽象出来公用，为了后期漏斗漏下来的用户，比如用户中心，比如用户产生的数据，后期在下游的产品怎么提高复用率。
- 功能层面需要可以复用，业务模块有非常多的重合度。
基于以上这2个方向
前端我们可以通过一系列的工程化和组件化来达到功能层面的复用性，由于组件的增加整个前端需要的开发人员会逐渐减少，可以释放大量的资源出来。ps：这块可以看看我之前写的一部分文章。
后端由于服务和数据的整合抽象，行程了一套围绕着项目的基础服务，基础服务的产生相对应的数据也会跟随着抽象出独立的数据。
假如一个用户从上层逐渐漏下来，然后他之前相关的生成的用户操作类数据，以及相对应的用户习惯也会跟随下来，所以即使在不同的系统中需要打通和数据，上面说的事情其实就是在干这块的事情。
前端和后端相应的组件和服务逐渐的满足业务的需求时，整体的资源会得到一定程度的释放，所以团队关注度开始围绕性能、异常、体验、监控来展开，整体的能力模型，从前端逐渐转移到其他方向。
后期也会开始增加服务发现、服务注册等，所以架构的选项其实是整体业务驱使你去做相应的升级和维护的。之前有遇到过上来就要上微服务，完全不管微服务对于当前团队的专业度、当前业务的适用性、后期维护成本等，最终形成僵局，团队内只有一俩个人可以维护的起来，团队管理上大量的精力放在不让这俩人跑路，其他人怨声载道。
我自己的团队建设原则是 技术无界
很多时候还是要靠业务上的引导和驱动来达到目标。
