关于微服务的一点理解

采用市面上常用的微服务框架或者拆分多个服务去部署就算是微服务了。就像原先在的公司说采用的是敏捷开发方式，实际上只是使用了一些敏捷开发的方法，并不能算是敏捷开发。只有遵守敏捷开发的价值观和原则，才能真正属于敏捷开发。微服务也一样。

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

此方案把压力推到了 Redis 中，包括缓存的读取、序列化等工作，基本上运行正常。突然有一次发版，因一些原因，停掉了其中一台服务，导致在业务高峰期出现了请求超时（数据加载不出来的情况）。

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

过后，运维方面提出了采用 Dubbo+zookeeper+RabbitMQ+SpringMVC/Springboot（分布式服务架构）来提升系统的可靠性和稳定性。

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

假设现在就引入微服务来解决出现的问题。

首先要解决的问题就是把目前的系统做分解（拆分），做到服务之间不相互调用、不用花大力气解决各个服务之间的数据一致性问题。这个也是微服务的真正难点（并非在于技术实现，而是业务的划分），做到微服务的第一步是识别限界上下文。

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

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

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