[汇总]微服务构架经验
1. 实施经验
这里提供了三种策略给大家参考，如图所示：
第一种 Cream Scoop Strategy 冰淇淋勺策略：是 Martin Flower 提出的一种策略，也被称为扼杀者方法。可以想象有一大桶冰淇淋，这桶冰淇淋就代表现有的架构，可以用勺子从桶中挖出你们想要的冰淇淋，这个挖出的部分就是要做拆分的服务。最终可以将大桶冰淇淋挖出一个个独立的服务，这里服务包含不同的业务逻辑。这种方式是逐渐修改原有系统，并且逐步对服务进行拆分试错然后过度到单独的资源上运行。每次拆分对系统的影响较小，但是整个系统的拆分和重构需要较长时间。
第二种 乐高法策略（搭积木），把原有的系统想象成一大块乐高积木，我们只需要往上面添加小的乐高积木模块就行了，添加的小模块就是一个个微服务。这样一来就不用对老产品进行调整，新的功能通过微服务的方式实现并且集成到老的产品中。不过需要通过一种能够让微服务与老产品联系的方法，这里会使用到接口编程以及适配器模式。
第三种是 nuclear 策略，和策略的名字一样我们需要对老旧系统推到重来，重新打造微服务架构，说起来容易这里需要花费大量分析和重构的时间，这个周期比较长，成本也是较高的。
先以包含 JVM 技术栈的微服务为例，这些微服务构建起稳定的应用程序并运行在 AWS 当中。对于此类微服务，我们监控的是 AWS 指标，例如 CPU 利用率、网络流量、内存以及磁盘使用率等。此外，我们还需要监控通信指标，例如负载均衡器状态如何、目前存在多少个健康实例、ELB 与实例之间是否存在连接错误、内部负载的响应速率如何、外部服务负载的响应速率如何、ELB 中的请求率如何、这些请求顺利进入了实例之内还是因无法连接而向客户端返回了错误提示等等。
再有，我们也建立起指向特定语言的指标。对于 JVM，我们需要监控线程数量，以了解我们的应用程序是否拥有良好的线程使用率，或者在完成某一线程中是否遇到了问题。我们还需要监控内存堆，借此了解我们的 JVM 设置是否正确，或者能够切实有效地整理出与后续改进相关的信息记录。
2. 失败经验
首先，微服务是采用分治法思想，需要对业务逻辑做分解。做完分解后，还需要多个对应的实现模块去实现分解后的业务问题。这些模块的开发和维护，是都需要成本的。
第二，微服务的另一个优势是弹性化。微服务里最佳实践是每个分出的模块应该都有自己的数据库，和别的微服务并不共享任何数据库。凭什么需要切分业务，从而搞出一大堆的项目出来呢？
第三，微服务起手就是分布式。分布式事务大家都知道有多困难的。你告诉我我说市面上有很多成熟的分布式事务解决方案？别自欺欺人了,微服务的提倡者老马丁自己也说，微服务引入了最终一致性问题。
第四，微服务互相之间是通过网络通信配合起来来对外提供服务的。这就会带来一个依赖性问题，即微服务非常依赖底层网络的健康。
![[转]微服务之间调用超时的设置治理](http://www.mobabel.net/wp-content/themes/hueman/assets/front/img/thumb-medium-empty.png)
