Fork me on GitHub

我对微服务架构的简单理解

在写架构的时候,就要想着,哪些功能是要以后可能要单独部署的,虽然一开始写的时候可以写在一个解决方案里,但那些请求的dto,和返回的视图,业务依赖,能随时独立出去,完全不需要做任何操作,即使是文件夹复制移动都不需要,就能够把该功能独立成一个解决方案,做到独立部署,然后通过远程接口的方法调用处理独立部署的业务;我认为这是微服务架构的最主要的作用。当业务多起来了,数据量大了,用微服务架构开发的应用,可以很快的把一个数据库拆分成不同的数据库,分服务器部署,实现突破业务瓶颈;
 
其实我理解的微服务,就是把以前一个接口一个数据库里实现的逻辑,改变为通过一级或多级远程调用去不同的服务器和数据库获取数据,然后完成整个逻辑。这也算是分布式开发技术了,每次业务要保证在多级远程调用过程中,数据的一致性,在存储数据时,因为是分不同数据库,不同服务器保存数据,有可能一个请求,要保存或更新a、b、c三个不同地区里不同服务器的数据库。就需要保证分布式数据保存的acid:原子性、一致性、隔离性、持久性。
 
虽然,我在工作中,没有太深入的接触这方面的内容,但感觉得出,这些微服务,分布式技术,只是有这个需求才产生的,以前分布式不火,因为那时候一个数据库curd就没有超过性能瓶颈,而且网络条件也不太发达,使用网络的用户也不多,现在,网络发达了,网民多了,产生的数据就变多了,对于一些企业,一个数据库就有性能瓶颈了,所以就需要分库开发,感觉分库就和微服务是十分匹配的。那些数据多的企业就需要使用这种技术,而那些业务量小的企业,而且数据量一直很稳定,或者并不是直接靠网络数据生存的企业,比如一些把计算机编程技术作为辅助的,其核心是生产制造一些电子产品、工业产品、应用食品的企业,这些企业中的中小型个体或集团其实可能不需要用到微服务架构吧,就不必花大功夫去想处理什么接口幂等、分布式事务这些分布式架构的缺点吧。
 
我感觉吧,任何事物,都是要随其自然,技术的更新迭代大多也是在于有现实的痛点或瓶颈的倒逼;不断解决这些瓶颈问题,就是在创新,就是在进步;人也一样,有的人有瓶颈了就成为他们的上限了,有的人就能解决瓶颈,实现进步。
posted @ 2024-05-25 15:40  HelloLLLLL  阅读(2345)  评论(17编辑  收藏  举报