对于微服务的一点思考

罗曼特 2019-04-15 01:4543 阅读

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

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

随着公司业务的发展,部门领导要求其中一个业务量比较大的要做负载。只给了一周的时间,包括开发和自测。因为时间比较紧,采用了最简单快捷的处理方式:缓存统一放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
版权归作者所有,转载请注明出处

回复数量: 0
暂无评论~~
  请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!