微服务的好处主要是针对传统的大型复杂服务而言
主要讲了什么时候划分出微服务，总结是，先内部分模块解决，再等界限清晰，最后划分微服务
模块和服务，不要过早使用微服务：微服务是目标做到、而且容易做到 高内聚低耦合的，当我们通过逻辑或者功能来划分时，比如一个进程内，可以优先考虑多模块划分，这也是一种减少耦合的方式。而这些模块的划分，也是以后划分微服务的最好备选。
所以一个新系统，如果界限不是特别清晰，可以先考虑做模块划分，因为服务之间的边界搞错了后面的修复代价很大。所以最好等成熟后，界限稳定后，再划分新的微服务。
集成是微服务相关技术中最重要的一个。也能很好的保持微服务自治性。
这些技术能够提供的好处显而易见，服务隐藏了内部实现细节、内部的技术细节，对外只暴露API，服务的内部修改也不影响外部的访问。
服务之间通过API相互访问，如果通过共享数据库，就会把数据库全都暴露出来，所有细节外部都能看到，而通过API的合理约束，数据库的很多实现就会被屏蔽，内聚性能得到很好的保证。
HTTP请求一般都通过JSON，这样请求的封装开销是个问题，明文传输更易于调试，而且现在流行程度也决定了它的适用性
RPC延时更低，很多都是二进制协议更高效，
微服务的时间发布和消费需要考虑异步，消息队列(Rabbit MQ等)是常见的选择，优势是 可订阅可消费，消息也有状态，不会重复消费，降低耦合，伸缩性好，劣势是使用有复杂度。不过已经是最优解
合理的服务要有自己的状态，比如服务有自己的配置db，每次操作服务就会更新db的值(状态)，避免服务成为贫血服务(即只做CRUD的简单服务)
经常遇见的一个情况，是新用户有新需求，那么可以做的选择是
- 同一个服务上做新的接口给新用户，老的接口给老用户，最后实现老用户迁移，最终停止使用老接口
- 同时使用多个版本的服务，每个服务独立对外提供接口
大部分情况下，还是第一种方案最适合，第二种方案过重。短时间使用两个服务也许是合理的，但是这样多个接口存在的时间越长，就越应该考虑第一种方案，
原文：https://www.cnblogs.com/jiangz222/p/10434526.html