[汇总]微服务构架经验

by leelight · Published April 12, 2019 · Updated May 26, 2021

先以包含 JVM 技术栈的微服务为例，这些微服务构建起稳定的应用程序并运行在 AWS 当中。对于此类微服务，我们监控的是 AWS 指标，例如 CPU 利用率、网络流量、内存以及磁盘使用率等。此外，我们还需要监控通信指标，例如负载均衡器状态如何、目前存在多少个健康实例、ELB 与实例之间是否存在连接错误、内部负载的响应速率如何、外部服务负载的响应速率如何、ELB 中的请求率如何、这些请求顺利进入了实例之内还是因无法连接而向客户端返回了错误提示等等。

再有，我们也建立起指向特定语言的指标。对于 JVM，我们需要监控线程数量，以了解我们的应用程序是否拥有良好的线程使用率，或者在完成某一线程中是否遇到了问题。我们还需要监控内存堆，借此了解我们的 JVM 设置是否正确，或者能够切实有效地整理出与后续改进相关的信息记录。

首先，微服务是采用分治法思想，需要对业务逻辑做分解。做完分解后，还需要多个对应的实现模块去实现分解后的业务问题。这些模块的开发和维护，是都需要成本的。

第二，微服务的另一个优势是弹性化。微服务里最佳实践是每个分出的模块应该都有自己的数据库，和别的微服务并不共享任何数据库。凭什么需要切分业务，从而搞出一大堆的项目出来呢？

第三，微服务起手就是分布式。分布式事务大家都知道有多困难的。你告诉我我说市面上有很多成熟的分布式事务解决方案？别自欺欺人了,微服务的提倡者老马丁自己也说，微服务引入了最终一致性问题。

第四，微服务互相之间是通过网络通信配合起来来对外提供服务的。这就会带来一个依赖性问题，即微服务非常依赖底层网络的健康。