对于微服务的一点思考

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

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

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

最后

以上就是大气自行车为你收集整理的对于微服务的一点思考的全部内容，希望文章能够帮你解决对于微服务的一点思考所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。