公司说我们的开发方式是敏捷开发,实际上只是使用了一些敏捷开发的方法,只有遵守敏捷开发的价值观和原则，才能算是敏捷开发。微服务也是一样，不是说拆分成多个服务去部署，就叫做微服务。也不是采用市面上常用的微服务框架，就是微服务了。
上面这段话是我对微服务的简单理解。
随着公司业务的发展，部门领导要求其中一个业务量比较大的要做负载。只给了一周的时间，包括开发和自测。因为时间比较紧，采用了最简单快捷的处理方式：缓存统一放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
版权归作者所有，转载请注明出处
原文地址：https://www.cnblogs.com/fishsky/p/10699980.html