某文读后感 与 OUT

 

同事推送过来的一篇文字--FROM 腾讯云，《不要在微服架构中使用单一数据库》看完以后就有了这段糙文，那篇文章是从开发的角度，或者说架构师的角度来看待在今天的系统集成中，或者说应该如何看待数据库。

我们先来看看几个"XXXX"的架构设计，与架构设计中使用数据库的模式。

如果用一句话来形容，这样的架构设计，Do you lost your mind ?

难道就那么喜欢，把所有的鸡蛋都放到一个篮子里面？  

身为架构师不光要考虑软件架构层的问题，同时也要考虑硬件架构以及系统的耦合性的问题。

在软件的架构都进行微服务化后，单一的数据库却成为一个承载所有微服务数据的地方，这是难以想象的。如同上图，ORACLE RAC 基于的是底层的存储层，为上层提供服务，而单点的性质就在 ORACLE RAC  的存储层。如果存储层稍有差池，整体的微服务任你拆的在散，消息传递的在有效可靠，都会被你不注意的单点毁于一旦。

当然你可以做 RAC 层底层的存储的冗余，但由此也不能说明你的微服务化是成功的，及时故障转移，他还是一个单点，不是吗。

抛去考虑 FAILOVER 的问题，性能的问题，也会在上面的设计中产生问题，假设，如果你出去游玩，你是愿意住在一个大通铺和10几个人一起挤，你还是愿意住单人间。 

如果你不是热衷“占便宜”，或者有特殊癖好的话，一般的人都倾向于去住单人间。单人间对自己和对别人都是可控的，隔离的，互相不影响的。

换到微服，也是这样，你是愿意你的微服后端都有条不紊的运行在分布式数据库中，还是都挤在 类似 ORACLE RAC 这样的大通铺中，随着你项目的增多，性能的争用会在数据库中爆发，然后你可能面临的就是迁库，或者再次提高单体数据库的某些性能和容量。

说到这里，到底为什么现在的软件开发不在愿意使用原来的方式去开发软件，而单单要提到 微服务，微服务框架来进行软件的开发。

       庞大的单块服务作为一个整体扩展，系统中只有一小部分存在性能问题,也需要对整个服务进行扩展，若使用较小的多个服务,只对需要扩展的服务进行扩展,这样就能避免很多不必要的麻烦并且可以部署在性能稍差的硬件上。

       在有几百万行代码的单块应用程序中，即使只修改了一行代码,也需要重新部署整个应用程序才能够发布该变更。这种部署的影响很大、风险很高,因此相关千系人不敢轻易做部署。于是在实际操作中,部署的频率就会变得很低。这意味着在两次发布之间我们对软件做了很多功能增强,但直到最后一刻才把这些大量的变更一次性发布到生产环境中。另一个问题两次发布之间的差异越大,出错的可能性就更大在微服务架构中,各个服务的部署是独立的这样就可以更快地对特定部分的代码进行部署。之间通过消息传递，消费（MQ）等方式来进行工作，如果某个模块出现问题，不会大面积影响其他模块，业务可能受到的损伤更小，或者根本就可以忽略。

而在软件设计上很明白的问题，反而到了数据库上就开始迷糊了，将所有的微服的数据放置到一个数据库这样的情况不少见，尤其传统行业里面做的很差劲。这其中有一部分是 架构师的问题，另一部分是管理数据库的人员的意识有问题，还活在 一库走天下的旧思维下。

 掌握多种数据库，来应付目前的软件开发模式，是一种必然。一个公司可能使用的数据库不在是1 种 2种，这就对数据库管理者提出了更高的要求。如果不能满足目前开发的模式，则这样的人员也必然会被淘汰。

最近一则新闻也是够奇葩，说某市的出租司机，将共享单车都扔到河里面，因为共享单车抢了生意，除了可笑以外，这些人也很可悲，妄图螳臂当车，也只能是成为笑谈。

同样数据库使用和管理的概念也在这波潮流中被改变，数据库可能不在变得更重要，很可能变得不重要，硬件的大幅度提升可能数据库优化也将变得不再重要或者以前认为不是数据库的东西，现在也属于数据库，例如 ES ， NEO4J,  服务的方式不同，服务的业务不同，更倾向于更专业的，有倾向性的降低开发和管理的门槛的产品，不再是贵的要死还没有特色的产品。

最后，说到开源数据库，类似于微服务这样的软件架构，并且正确设计其底层的数据库，一定不是类似上图那样的设计，反而和可能是下图这样的方式，而作为一个企业成本是重要的，脱离成本谈任何问题都没有底气，而如何节省成本，并且在节省成本的同时也能满足企业的需求，满足开发的需求才是一个数据库架构师应该做的。