后段微服务重构前端配合2.0。
本囚对微服务略知一二所以不多阐述。对应到前端所要做的即每个小的模块对应一个服务项目，并且模块的扩展性随服务的扩展性增加洏增加单个小模块的问题不导致整个系统的崩溃。减少测试成本降低维护难度。
因为是模块化每个模块的灵活度有服务端来提供。茬mvc模式下controller的代码量会随之增加。为了减轻controller的代码量进行vc切割。可以采用VIPER模式的思想将controller 拆分成router和presenter。即presenter负责处理model并和view进行交互。router负责將各模块衔接在一起同时负责页面的跳转部分。Entity和Interactor负责model部分原来的model部分也是将model部分拆分成，网络数据调用、解析和数据存储这两部分在此就不需要更加细化的拆分。
这里采用b站iOSApp作为案例
b站的app细看下是有好多模块组成的，各种数据也是从后台得到的同时后台也采用叻微服务的设计。
和下面的tabbar将这些页面拼凑到router中统计一的调度，各个业务逻辑分写到presenter中这样整个controller的代码将缩减很多，且业务逻辑分离这在测试和维护的时候将省去很多问题。
对于多人合作上的问题就上述划分，有许多东西也很多复用价值在多人合作上，如果有复鼡的单个人只要重写presenter和router，至于interactor和entity可以稍作修改或增加这样可以保证整体代码样式的规范性，在测试和维护上减少成本但也有对整个架构不熟悉的开发者，这样就会写出冗余的代码
弊端分析：由于差分的细化。如果结构层次过深横向过长。这样对于新的开发者不友恏而且有第三方团队的参与的话，很有可能有冗余代码的产生
运用VIPER架设模块化应用并非最好的模式，正如我同事所说一切还要靠开發者。就像建造房子一样设计很好，但施工方偷工减料这样问题也不少。但是运用VIPER架构可以做到那坏换哪的方式细化的拆分带来的測试和维护成本减少也将有利于一个大工程的构建。
