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