1、大量使用RPC
方便业务功能接口化，复用升级较为方便。
老代码，直接查库，到处都在查库，不方便维护升级，性能问题到处都是。
开发效率偏低。
对外合作，直接RPC调用，也方便。
2、大量使用Redis
大大降低了数据库压力，提升了接口调用性能。
托底缓存1个月也是很不错的。
3、ElasticSearch
数据库适合最底层最准确的数据存储，Redis适合临时缓存，过期自动失效。
而ES适合2者之间的，数据较为准确，缓存又不太合适，比如 用户的评论列表。
个人认为，ES和Solr很类似，就是一个“宽表”，把关系型数据库中的多张表转换成1张表，建立索引，或者分词，还可以。
项目的趋势是，尽可能“脱库”。凡是不要求非常实时，不能出问题的，都尽可能用ES。
用户的订单订购、退款，涉及到状态变更、支付的，走数据库。
4、缓存
本地JVM缓存Guava有封装的、普通Redis缓存、托底缓存。
ES也有点接近缓存的意思，人为手动更新，比如在后台修改的时候，或者自动更新，每天的定时任务。
定时任务，主要采用全量更新，分2种。1种是无论是否有变化，都用数据库的更新一遍。
2种是把数据库和ES中的对比一下，发现变化了，才重新index一次，更加高效。
5、AOP用的多用的好
Controller、Service、RPC、Manager、Dao，各层都有 监控日志拦截，统一报警。
6、降级机制
大量存在降级机制，通过配置中心的开关，万一不可用，切换一下。
然后，程序可以直接使用Redis托底缓存的数据，或者不对外提供服务。
坏处是，代码可读性越来越差。尤其是在复杂流程中，各种开关，非常烦躁。
伪降级：系统中存在2个系统融合的代码，维护了2套流程，通过开关/订单类型等字段，一会切换到老流程，一会切换到新流程，
这绝对不是降级。
7、分红协作
流量较大，人较多，分工协作是个问题。
偏业务，技术不是重点。
敏捷不敏捷，更多是一种形式，一种管理方式。
学习其优点，忽视其不足。
8、强力吐槽
系统业务不断交接，人员不断更换，老代码逐步过时，新人读代码改改改。
业务不清晰，后面的人被前面的坑，恶性循环。随便一个公司，都有此类问题。
2个系统融合，没有思考清楚，就干起来，一直维护2个老流程+1套新流程，很烦。
一直忙于业务，技术较落后，struts2和ibatis语法都懒得复习了，凑合着用。新项目不可能用和2个古董了。
重构是永远的痛，干的好是理所应当的，也没啥业绩。搞出问题了，得负责。趋于保守，不可避免。
数据库各种联表查询，又难懂，性能又低，难维护。
玩技术，系统用的技术也越来越多，不恰当，系统各种问题。
滥用设计模式，代码难懂，不好维护。
不断总结实践，形成自己的技术思想体系，不断实践。
1种是适合中型项目的。
1种是适合小项目的。
超级流量，高大上的技术，没啥兴趣。
小雷FansUnion
2018年11月2日
北京