十八年的开发经历，从制造业到金融到自己创业，一直忙忙碌碌，代码写得多，文章写得少，这些年也从网上看了不少前辈的文章，学了不少，眼看自己也过了招聘线了，怎么算也是前辈了，是时候将自己的经验分享出来，反馈社区，我看网上入门的教程多，真的将一套可用的系统从0开始的教程很少，从这套优化多年的框架开始吧，争取把这套框架从如何架构的理论到服务器如何布署一步步讲清楚。

        先说框架优势和原理：

。代码少：传统的CRUD完全无需写代码，除了省代码的功夫，其实更主要的是质量更高，普通增删查改多数都是初级程序员来写，BUG多语法错误都有，没有代码就没有错误，多做多错少做少错不做不错。

。开发速度快：互联网项目我觉得就应该快速迭代，快速试错，快速响应业务部门和客户的需求，怎么快，其实和上面的代码少有很大相关，代码越少开发越快，代码越少BUG越少出问题少上线更快，这是很明显的道理。

。并发性能强：做游戏辅助项目的时候，尝试过一台1核2G的云服务器支撑上千并发，CPU和内存均未满载，当然这是NODEJS的语言特性，并非框架功劳，不得不说NODEJS在API并发方面的性能，与JAVA .NET PHP的差别简直是肉眼可见，当然NODEJS剑走偏锋，是专门为了高并发诞生的，也不是完全没有缺点的，需多了解其特性，用其长避其短。

。可扩展性强：要做到可扩展，首先就是要支持多种数据库，同时同种数据库支持多个，然后就是要做到中间服务器无状态化，无状态服务器意味着可以随时增加，只要接上域名轮询、负载均衡、NGINX等手段，意味着承接请求的处理能力是无限的，可支持多种及多个数据库，意味着采取分而治之的手段，后端数据库的能力也是无限的。(希望预算也是无限的。。。）

。可局部重构：这个我觉得是亮点，值得好好说道说道。最早开始学开发的时候，虽然系统不大，用的人也不多，但是水平也有限，隔一阵总会发现系统有不完善的地方，做开发的多少有点强迫症，追求完美，不知道就算了，知道了如何能忍！怎么办呢，只有重构了，然后刚弄好又发现。。。周而复始，感觉自己象个陀螺。。。而且每次重构总是从头开始全部重写一遍，工作量也太大了，有些又是完全没必要的，比如我想让仓库支持双单位，这个又不关人事系统和用户鉴权系统的事，为嘛要重头开始重写呢？能不能找到一个办法，我们只重构仓库系统，却保持其它系统不变呢？其实有很多系统有这样的问题，设计时没有办法考虑到未来的情况，一旦开始使用，用户量和数据量逐日增长，发现有问题没考虑到，要重构太难了，都是一边维护现有系统，一边开发新的，工作量大可能要几年时间才能完成大改，届时市场能不能等就是两说了。。。如果能有局部重构的能力，就是边开车边换胎，市场和业务变化，系统能迅速响应更新甚至重构，公司的适应力和生存能力将大幅提升，项目成功的机率也会大增了，快速适应的能力重要性怎么强调都不过分。那么我们如何实现局部重构的能力？首先是高内聚低耦合，微服务的概念，三五类组成一个模块，对外视作一个整体提供接口服务，小修改不用说，大修改重构一整个模块，也就三五个类，工作量和复杂度比起重构整套系统就小得多了。具体来说，API分为4层：第一层为API版本号，第二层为微服务名称，第三层为类名，第四层为方法名。例如：api15/ucenter/users/login 即15年版本的 用户鉴权中心 user这个类的登录方法 实际运行中我们的多套系统api版本号已到18但用户鉴权逻辑因为没有大改 实际还在使用15年的版本

。支持帐套：SAAS系统多个不同的公司共享一套代码一套服务器和数据库资源，同时数据相互不可访问

。个性化：通过各种开关和配置表，实现不同的用户展现不同的后端逻辑和前端页面。例如：张三公司是双单位的库存系统，李四公司是普通的，后台处理的逻辑就会不同，王五公司有订制不同的特殊报表打印页，当王五公司打开报表时，展示和其它用户又不一样，当然如果每个公司不同太过麻烦一般也是弄几个模板，通过开关或配置文件来处理

。。。其它玩法不可胜举，我们做应用开发，虽没有太多高精尖，但做为最接地气的领域，其实更需要既懂业务又懂技术，才能用好IT这个工具，服务公司进而服务广大客户。