对于微服务的一点思考

Posted fishsky

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了对于微服务的一点思考相关的知识,希望对你有一定的参考价值。

公司说我们的开发方式是敏捷开发,实际上只是使用了一些敏捷开发的方法,只有遵守敏捷开发的价值观和原则,才能算是敏捷开发。微服务也是一样,不是说拆分成多个服务去部署,就叫做微服务。也不是采用市面上常用的微服务框架,就是微服务了。

上面这段话是我对微服务的简单理解。

随着公司业务的发展,部门领导要求其中一个业务量比较大的要做负载。只给了一周的时间,包括开发和自测。因为时间比较紧,采用了最简单快捷的处理方式:缓存统一放Redis,起了一个辅助项目来做公共和定时器等方面的处理。

此种方式基本把压力推到了Redis中,包括缓存的读取、序列化等工作,基本上运行正常。突然有一次发版,因一些原因,停掉了其中一台服务(详见https://www.cnblogs.com/fishsky/p/10593233.html),导致在业务高峰期出现了请求超时(数据加载不出来的情况)。

重启开启另外一台负载后 ,运行正常。过了两天,又出现部分请求超时的情况。定位看到,其中一台负载遇到了瓶颈,追查原因是haproxy采用的source的负载规则(以请求源IP为判断,转发到一台服务器后,后面只会到那台机子上)。为了避免再次出现情况,部署多了一台机子,即共3台,进行负载,采用的是balance roundrobin (轮询),基本稳定下来。

此时,运维方面提出了采用Dubbo+zookeeper+RabbitMQ+SpringMVC/Springboot(分布式服务架构)来提升系统的可靠性和稳定性。

对于此方案,初衷是好的。不过要实现落地,达到公司系统架构的调整,直接引入这套架构,并不是最好的选择。投入的成本较高。如果不采用微服务(或者分布式服务架构)能否解决现在的问题,答案是肯定的。

好像有点偏离主题了,按现在我们就假设现在是引入微服务来解决出现的问题。

首先要解决的问题就是把目前的系统做分解(拆分),做到服务之间不相互调用、不用花大力气解决各个服务之间的数据一致性问题。

这个也是微服务的真正难点(并非在于技术实现,而是业务的划分),做到微服务的第一步是识别限界上下文。

对业务的划分,目前有一套从系统分析到软件建模的方法论:领域驱动设计。它要解决的问题是:将业务概念和业务规则转换成软件系统中概念和规则,从而降低或隐藏业务复杂性,使系统具有更好的扩展性,以应对复杂多变的显示业务问题。

想做微服务架构,首先是不要使用微服务。如果将一个整体服务贸然做成微服务,引入的复杂度会吞噬掉你以为的优势。

可以采用,让不同的限界上下文先各自独立演化,等到它演化到值得独立部署了,再来考虑微服务拆分的事情。那时各种微服务(分布式服务)的技术,才是真正上场的时候。

作者:鱼天翱
出处:https://www.cnblogs.com/fishsky
版权归作者所有,转载请注明出处

以上是关于对于微服务的一点思考的主要内容,如果未能解决你的问题,请参考以下文章

中小型公司对于Spring Cloud的选择与思考

从微服务划分,微服务之间通信到程序员能力提高的一些思考

关于SpringCloud微服务架构概念的一点理解

「微服务架构」Medium的微服务架构实践

微服务架构-从理想到现实

微服务架构学习与思考(04):微服务技术体系