套路1，微信拉新，app留存
套路2，三层足以
反对微服务架构：（评：有不同意见）
- 系统成本。
- 开发成本。
- 升级成本。
缓存技术：内存、分布式缓存、URL缓存
软件架构的原则：Keep It Simple，Stupid！
从0开始的企业，应该保持稳重踏实的步伐，不要觉得既然今后要拆分，前期就干脆一步到位——因为能否活到那一步都是未知数。技术的重心应放在业务模块的垂直划分，做好模块之间的独立于松耦合，尽量杜绝模块之间的依赖过多，做好今后模块拆分独立的准备即可。
套路3，构建能复用的组件
-
基础组件
-
Docker
-
持续集成，发布。
-
日志中心。（ELK）
-
项目组件
-
基于微信的用户组件
用户注册（包括手机短信接收、二维码、微信绑定）、用户登录、用户信息展示与修改。 -
支付组件
-
后台管理系统
- 员工，部门信息管理
- 权限，角色控制
- 负责查询列表页的基础SearchModel
复杂查询列表页的开发有几个麻烦的地方：- 查询条件的数量非常多，输入和不输入查询项则对SQL拼写有很大的影响。+
- 要注意前端页面输入项的SQL注入可能。
- 对于不控件的查询表达式不一样得单独处理，比如有的是用Like，有的是用Equal……
基本思路是： - 构建一个请求的拦截器，处理和整理浏览器传回服务端的请求中带有复查查询条件标示的参数。
- 构建一个复杂查询对象SearchModel，可以保存所有的查询域、查询值、表达式符号、and/or等SQL组装所需要的信息。+
- 将复杂查询对象SearchModel通过ORM框架（Mybatis/Hibernate）转化为SQL查询条件，并执行查询语句。
- 在页面处理查询语句返回的结果，将其绑定到页面上的Grid中。
转自：https://comet-project.gitbooks.io/cto-tech-manual/content/chapter2/longyin.html
网友评论