公共库解耦

个性业务代码上浮，共性业务代码服务化下沉，只是一个很小的优化点，但对于公共库解耦却是非常的有效。

使用内网域名来替换内网IP

• 运维修改内网DNS，将内网域名指向新的IP，如果是短连接调用，未来新的请求流量，自然会切到新的IP上；如果是长连接调用，新的长连接会连到新的IP上，但旧的长连接仍然连接的是旧IP • 运维统一将旧IP上的连接切断，如无意外，服务或者数据库的连接池都有重连功能，重连后就会自动连到新IP上去

设计数据库中间件

（1）统一接入入口 （2）保持访问接口 （3）屏蔽读写分离 （4）支持的分库 （5）高可用性的支持 （6）可运维性的支持

为什么要引入数据库中间件

当数据库水平切分，base-service层获取db数据过于复杂，成为通用痛点的时候，就应该抽象出数据库中间件，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性。

互联网分层架构，为啥要前后端分离

当业务越来越复杂，端上的产品越来越多，展现层的变化越来越快越来越多，站点层存在大量代码拷贝，数据获取复杂性成为通用痛点的时候，就应该进行前后端分离分层抽象，简化数据获取过程，提高数据获取效率，向上游屏蔽底层的复杂性。 这样的好处是： • 复杂的业务逻辑与数据生成，只有在站点数据层处写了一次，没有代码拷贝 • 底层service接口发生变化，只有站点数据层一处需要升级修改 • 底层service如果有bug，只有站点数据层一处需要升级修改 • 站点展现层可以根据产品的不同形态，传入不同的参数，调用不同的站点数据层接口 除此之外： • 产品追求绚丽的效果，并对设备兼容性要求高，不再困扰Java工程师，由更专业的FE对接 • 一点点展现的改动，不再需要Java工程师们重新编译，打包，上线，重启tomcat • 约定好json接口后，Java和FE分开开发，FE可以用mock的接口自测，不再等待一起联调

OceanBase云时代的关系数据库

OceanBase云时代的关系数据库：OceanBase应对之道，OceanBase产品进展

O2O搜索优化实践之道

O2O搜索优化实践之道：o2o搜索推荐业务介绍、搜索推荐的特殊挑战、在工程和算法上的实践

慢SQL优化In PostgreSQL

1、Create Index Directly 2、Change Conditions to Use Index 3、尽量避免在where子句中对字段进行运算，导致查询规划器放弃使用index 4、尽量避免在where子句中对字段类型进行强制转换，导致查询规划器放弃使用index 5、少用outer join，减少不必要的sub-query层级数【在不影响得到正确结果的前提下】 6、坚决避免select * 和 redundant columns【多余字段】 7、Index on Expressions 8、Partial Indexes 9、Decompose DDL【分解DDL】 10、Comprehensive optimization【综合优化】 11、索引的创建 12、查找需要删除的索引 13、查找重复的索引 14、查找需要维护的索引，并自定创建索引维护SQL 15、一个index size影响query plan的例子

O2O商业变现的架构探索-外卖广告架构实践

O2O商业变现的架构探索-外卖广告架构实践（O2O+广告）

mysql集群化的三种武器-MNC,MGC与MIC

mysql集群化的三种武器-MNC,MGC与MIC，参考《Mysql运维内参》