“微服务架构下需要什么样的数据库?”作为一个数据库开发人员，深知应用技术和数据库技术的紧密关系，自从知道微服务这个概念以来，这个问题就一直萦绕在我的脑海中。后来参与一个大型的金融企业业务上云微服务改造项目，并亲自完成了数据层的改造，这才对微服务对数据库技术的影响有了直观的认识。
因为涉及到企业隐私，就以网上比较通用的一个业务模型举例。传统企业应用服务架构采用的是“巨石”架构，也就是将所有“大脑”集中在一起，以 CS 架构为代表，将所有的逻辑放在一个应用中。在这种架构下，所有业务模块的数据都集中到一个数据库中，即使在最开始的业务设计时进行了比较清晰的表结构划分，但获取数据最方便的方式就是直接关联表数据。一般的开发团队也不会对跨模块的信息传递做硬性规定，只要性能能抗的住，SQL语句就没问题，一旦有问题DBA给抓出来再打回去重改。
传统应用的巨石架构
久而久之，数据库的表越来越多，越来越复杂，最后可能没有一个人能说清楚每个表都是干什么的;SQL语句可能也越写越复杂，两个表关联、三个表关联，套上几层子查询... 不久数据规模进一步增大，SQL已经不能通过调优解决了。这时一般的做法是，再换上一套更新的小机，再加上最新的高端阵列，好像又可以运转飞快了。
如果世界没有什么变化，这一切看起来也不错，传统三件套价格虽高，但还算非常稳定。可是传统业务也都逐渐由各地分布走向集中管理和运维，而且面向互联网的业务也逐渐增多，这样对系统提出了新的要求，总结起来就是4S [1]，
微服务
4S本身有很广的内涵，具体到数据库技术层面可以总结为：
“Scale”系统可以随数据量的急剧增加要能够随需伸缩;
“Speed”服务请求响应时延要低;
“Safety”服务质量和稳定性要求高;
“Sharing”系统资源可以共享;
微服务架构
虽然应用做了微服务拆分，但并不代表数据规模一定会小，某些服务(如订单服务)的数据库由于数据逐渐累积，会逐渐膨胀，超出单个数据库实例的管理能力;其次互联网类应用访问量会随着某些活动而发生剧烈波动，比如在双11、618促销中访问量通常是平时的2倍以上，需要提前对后台处理能力进行扩容，所以微服务会部署到企业私有云或者公有云平台上，数据库自然也需要支持云平台管控。然后各种微服务的数据类型，业务模型都有差异，以前在一个库里都只能遵守同样的数据分片方案，现在拆分后，完全可以根据业务特点采用不同的数据分片方案。另外一个具备企业级性能、可靠性数据库引擎也是必不可少的。最后，如果要支持更高的可用性，需要采用多中心部署，为了在不降低性能的情况下保证RPO=0，支持分布式一致性协议必要的。
可见微服务时代，业务对数据库的要求不是更低了而是更高了，需要这样的一个数据库：
1、支持云化部署或者多租户管理能力;(“Sharing”)
2、支持在线水平扩容和水平缩容;(“Scale”)
3、支持多种数据分片方案(哈希、列表、范围)，这样可以根据业务特点灵活选择，保障性能最优;(“Speed”)
4、支持完美分片和两阶段事务自适应，保障性最优;(“Speed”)
5、企业级稳定及高性能的数据库引擎;(“Safety”\“Speed”)
6、通过分布一致性协议支持多副本在多地多中心灵活部署;(“Safety”)
