昨天听了Gdevops峰会北京站的很多分享，自己也做了一个基本的总结，放出来一部分的PPT内容。

  一个是当当架构师张亮对于JDBC-sharding的分享，里面更多的讲了这个工具设计的初衷，碰到的问题，其中不乏很多技术方案的对比，比如下面这个，是上升到了更高的层级去看到RDBMs,NoSQL,NewSQL，可见各种方案之间目前都有一个基本的平衡，随着技术复杂度的变化，流行度也有相应的变化，目前来看还是RDBMS独占天下，而NoSQL,NewSQL的适用场景也会随着技术成熟度的提高而逐步分解RDBMS的占有量。

   现在随着数据量的增长，对于数据库层面的挑战也会越来越大。读写分离，sharding就是不可避免的问题，正如下的架构图，也可以解决分裤分解表的问题，也可以做sharding,但是实际的情况下，碰到了很多问题。

不如看看这个方案，引入了中间件，架构层次也清晰多了，但是这个图如果下钻，还有很多需要扩展改进的地方。

所以满足了基本的分库分表，RDBMS有自身的优势，也有不适合它的场景。

在分片规则上，这个分片策略让人耳目一新。

而如果选择数据库中间件方案，也有几种套路。很多都是基于proxy的方式来做，如果你的企业中用到的Java较多，那基于JDBC的数据库中间件就大有用武之地。

  阿里云RDS的架构设计演进的内容，也推出了不少的干货。BAT在这方面起步很早，也积累了很多独有的经验，但是一个高速发展的公司，无论是公有云，私有云，基于安全，基于性能，由内而外的无穷无尽的需求，这也是云团队的一个大苦恼。

这个DBaas的方案就很赞，很多都定格在了数据库的大量常用工作范畴。如果这部分工作能够做到一个用户体验更好，更易用一些，会缩短自己对于数据库技术理解的周期。

这个架构图我看了深有感触，一个核心的系统，大平台的系统的架构设计不是一蹴而就，都是不断的改进，踩坑，我们的数据库管理或者是运维工作就有很大的提升空间，通过平台化，通用化，能够分分钟甩锅，不背锅。

关于有状态服务的自动恢复，这个涉及到很多链路的情况，如果保证数据访问的可持续性，就是一个很有挑战的任务。

关于中心化到单元化，这种多数据中心的架构设计，对于数据一致性的要求极高。虽然很多公司暂时还不具备这样的体量，但是值得吸取的就是俩面的经验所得。

关于K8s和MySQL的集合，沃趣的小伙伴分享的内容，我觉得最赞的就是关于K8s上面部署MySQL的录屏演示，而对于性能的差异上，这个性能对比图就很有借鉴意义。

K8S现在实在太火了。谷歌集合多年的经验所得，在github上都是万级的星标。

 贺春旸老师分享的内容很全面，把MySQL,MongoDB,大数据的内容和整合真心化了很的的功夫去准备，内容很赞，对于高可用方案的MHA做了很多深刻的解读。

这是Percona的建议清单。

本文分享自微信公众号 - 杨建荣的学习笔记（jianrong-notes）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。