简而言之，微服务架构风格就是将单一应用的开发分为多个小的服务，每个小的服务在自己的进程中运行并使用轻量级机制进行通信（通常是一个HTTP API源），这些服务围绕业务性能进行构建，并且通过完全自动化的部署机制独立的部署。这些只需要最低限度的集中管理的服务，可以使用不同的编程语言编写，以及使用不同的数据存储技术。---- Martin Fowler的博客
( 单体架构 )
（ 微服务架构 ）
解决了代码臃肿的复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。虽然功能数量不变，但是应用程序已经被分解成可管理的块或者服务，个体服务能被更快地开发，并更容易理解与维护。
分割明确，使得保持团队之间的界限变得容易。微服务架构使整个系统的分工更加明确，责任更加清晰，每个人专心负责为其他人提供更好的服务。在单体应用的时代，公共的业务功能经常没有明确的归属。最后要么各做各的，每个人都重新实现了一遍；要么是随机一个人做到他负责的应用里面。
服务可以独立部署。如果你的应用由单个进程中的多个库组成，则对单个组件的任何更改都将导致不得不重新部署整个应用。但是，如果将应用分解为多个服务，你可以期望单个服务的更改只需要重新部署该单个服务即可。
微服务架构缺点
微服务架构整个应用分散成多个服务，定位故障点非常困难。
稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。
服务数量非常多，部署、管理的工作量很大。
服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。
微服务架构四大问题
客户端如何访问这么多的服务器
通过API网关
服务与服务之间如何通信
同步通信-HTTP/RPC
异步通信-消息队列 kafka RabbitMQ RocketMQ
这么多服务，如何管理
服务治理
服务注册与发现
基于客户端的服务注册与发现 Apache Zookeeper
基于服务端的服务注册与发现 Netflix Eureka
服务挂了，怎么办
重试机制
服务熔断
服务降级
服务限流
我的个人博客站