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

网友投稿 783 2022-05-30

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

因为涉及到企业隐私,就以网上比较通用的一个业务模型举例。传统企业应用服务架构采用的是“巨石”架构,也就是将所有“大脑”集中在一起,以 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”)

参考:

微服务 SQL 数据库

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:序列特征的处理方法之二:基于卷积神经网络方法
下一篇:API经济下,如何玩转API?
相关文章