国内最专业的IT技术学习网

Mysql数据库

当前位置:主页 > Mysql数据库 >

微服务架构下需要什么样的数据库

发布时间:2019/07/30标签:   数据库      SQL      技术    点击量:

原标题:微服务架构下需要什么样的数据库

“微服务架构下需要什么样的数据库?”作为一个数据库开发人员,深知应用技术和数据库技术的紧密关系,自从知道微服务这个概念以来,这个问题就一直萦绕在我的脑海中。后来参与一个大型的金融企业业务上云微服务改造项目,并亲自完成了数据层的改造,这才对微服务对数据库技术的影响有了直观的认识。

因为涉及到企业隐私,就以网上比较通用的一个业务模型举例。传统企业应用服务架构采用的是“巨石”架构,也就是将所有“大脑”集中在一起,以 CS 架构为代表,将所有的逻辑放在一个应用中。在这种架构下,所有业务模块的数据都集中到一个数据库中,即使在最开始的业务设计时进行了比较清晰的表结构划分,但获取数据最方便的方式就是直接关联表数据。一般的开发团队也不会对跨模块的信息传递做硬性规定,只要性能能抗的住,SQL语句就没问题,一旦有问题DBA给抓出来再打回去重改。


传统应用的巨石架构

久而久之,数据库的表越来越多,越来越复杂,最后可能没有一个人能说清楚每个表都是干什么的;SQL语句可能也越写越复杂,两个表关联、三个表关联,套上几层子查询... 不久数据规模进一步增大,SQL已经不能通过调优解决了。这时一般的做法是,再换上一套更新的小机,再加上最新的高端阵列,好像又可以运转飞快了。

如果世界没有什么变化,这一切看起来也不错,传统三件套价格虽高,但还算非常稳定。可是传统业务也都逐渐由各地分布走向集中管理和运维,而且面向互联网的业务也逐渐增多,这样对系统提出了新的要求,总结起来就是4S [1],


微服务

4S本身有很广的内涵,ui设计师骗局,具体到数据库技术层面可以总结为:

“Scale”系统可以随数据量的急剧增加要能够随需伸缩;

“Speed”服务请求响应时延要低;

“Safety”服务质量和稳定性要求高;

“Sharing”系统资源可以共享;


微服务架构

虽然应用做了微服务拆分,但并不代表数据规模一定会小,某些服务(如订单服务)的数据库由于数据逐渐累积,会逐渐膨胀,seo 404,超出单个数据库实例的管理能力;其次互联网类应用访问量会随着某些活动而发生剧烈波动,比如在双11、618促销中访问量通常是平时的2倍以上,需要提前对后台处理能力进行扩容,所以微服务会部署到企业私有云或者公有云平台上,数据库自然也需要支持云平台管控。然后各种微服务的数据类型,业务模型都有差异,以前在一个库里都只能遵守同样的数据分片方案,现在拆分后,完全可以根据业务特点采用不同的数据分片方案。另外一个具备企业级性能、可靠性数据库引擎也是必不可少的。最后,如果要支持更高的可用性,需要采用多中心部署,为了在不降低性能的情况下保证RPO=0,支持分布式一致性协议必要的。

可见微服务时代,业务对数据库的要求不是更低了而是更高了,用php开发网站,需要这样的一个数据库:

1、支持云化部署或者多租户管理能力;(“Sharing”)

2、支持在线水平扩容和水平缩容;(“Scale”)

3、支持多种数据分片方案(哈希、列表、范围),这样可以根据业务特点灵活选择,保障性能最优;(“Speed”)

4、支持完美分片和两阶段事务自适应,保障性最优;(“Speed”)

5、企业级稳定及高性能的数据库引擎;(“Safety”\“Speed”)

6、通过分布一致性协议支持多副本在多地多中心灵活部署;(“Safety”)

【编辑推荐】

MySQL和PG到底哪个更好用?

如何快速定位MySQL 的错误日志(Error Log)?

如何避免回表查询?什么是索引覆盖? | 1分钟MySQL优化系列

数据库集群方案及Oracle RAC架构分析

数据库软件架构,到底要设计些什么?

版权信息Copyright © IT技术教程 版权所有    ICP备案编号:鲁ICP备09013610号