《微服务架构下需要什么样的数据库？作为一名数据库开发人员，深知应用技术与数据库技术之间的密切关系。自从知道微服务的概念以来，这个问题就一直萦绕在我的脑海中。后来参与了一个大型金融企业上云微服务改造项目，亲自完成了数据层的改造。才对微服务对数据库技术的影响有了直观的认识。因为涉及到企业隐私，我们以互联网上比较常见的一种商业模式为例。传统的企业应用服务架构采用“单体”架构，即将所有的“大脑”聚集在一起，以CS架构为代表，将所有的逻辑都放在一个应用中。在这种架构下，所有业务模块的数据都集中在一个数据库中。即使在最初的业务设计中就明确划分了表结构，最便捷的获取数据的方式还是直接关联表数据。普通的开发团队不会对跨模块的信息传递做硬性规定。只要性能能承受得住，SQL语句就没问题。随着传统应用程序的单体架构，随着时间的推移，数据库中的表越来越多，变得越来越复杂。最后，可能没有人能够清楚地解释每个表的作用；SQL语句也可能变得越来越复杂。两张表关联，三张表关联，再加上几层子查询……很快数据规模进一步增大，SQL已经无法通过调优来解决了。这个时候一般的做法就是换上一套更新的小型电脑，再加上最新的高端阵法，看来又可以跑得飞快了。如果世事无变，这一切看起来都不错，传统三件套的价格偏高，但还是很稳定的。但传统业务正逐渐从本地分布向集中管理和运维转变，面向互联网的业务也逐渐增多，这对系统提出了新的要求，可以概括为4S[1]。微服务4S本身就有广泛的应用。其内涵，具体到数据库的技术层面，可以概括为：“规模”系统随着数据量的快速增长而膨胀和收缩；“速度”服务请求响应延迟应该低；“安全”服务质量和稳定性要求高；“共享”系统资源可以共享；虽然微服务架构已经拆分成微服务，但并不意味着数据规模一定要小。由于数据的逐渐积累，一些服务（如订单服务）的数据库会逐渐膨胀，超过单个数据库实例的管理能力；其次，互联网应用的流量会随着某些活动而剧烈波动。比如双十一、618的流量通常是平时的两倍以上，需要提前扩展后台处理能力，所以微服务会部署在企业私有云或者公有云平台上，数据库自然需要支持云平台管控。然后，各种微服务的数据类型和业务模型是不同的。过去，一个图书馆只能遵循相同的数据分片方案。现在拆分之后，可以根据业务特点采用不同的数据分片方案。另一个具有企业级性能和可靠性的数据库引擎也是必不可少的。最后，如果要支持更高的可用性，需要采用多中心部署。为了在不降低性能的情况下保证RPO=0，需要支持分布式共识协议。可见，在微服务时代，业务对数据库的要求不是更低而是更高。需要这样的数据库：1.支持云端部署或多租户管理能力；(“分享”)2.支持在线横向扩展和横向收缩；("Scale")3.支持多种数据分片方案（hash、list、range），方便您根据业务特点灵活选择，保证性能最优；("Speed")4.支持完美分区Shard和两阶段事务自适应，最优保证；(《极速》)5.企业级稳定、高性能的数据库引擎；(“安全”\“速度”)6.通过分布式一致性协议支持数据库多副本多地多中心灵活部署；（“安全”）
