微服务netflix 启动顺序

什么是微服务架构

简而言之，微服务架构风格就是将单一应用的开发分为多个小的服务，每个小的服务在自己的进程中运行并使用轻量级机制进行通信（通常是一个HTTP API源），这些服务围绕业务性能进行构建，并且通过完全自动化的部署机制独立的部署。这些只需要最低限度的集中管理的服务，可以使用不同的编程语言编写，以及使用不同的数据存储技术。---- Martin Fowler的博客

( 单体架构 )

（ 微服务架构 ）

微服务架构优点

• 解决了代码臃肿的复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。虽然功能数量不变，但是应用程序已经被分解成可管理的块或者服务，个体服务能被更快地开发，并更容易理解与维护。
• 分割明确，使得保持团队之间的界限变得容易。微服务架构使整个系统的分工更加明确，责任更加清晰，每个人专心负责为其他人提供更好的服务。在单体应用的时代，公共的业务功能经常没有明确的归属。最后要么各做各的，每个人都重新实现了一遍；要么是随机一个人做到他负责的应用里面。
• 服务可以独立部署。如果你的应用由单个进程中的多个库组成，则对单个组件的任何更改都将导致不得不重新部署整个应用。但是，如果将应用分解为多个服务，你可以期望单个服务的更改只需要重新部署该单个服务即可。

微服务架构缺点

• 微服务架构整个应用分散成多个服务，定位故障点非常困难。
• 稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。
• 服务数量非常多，部署、管理的工作量很大。
• 服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。

 

微服务架构四大问题

1. 客户端如何访问这么多的服务器

通过API网关

1. 服务与服务之间如何通信

同步通信-HTTP/RPC

异步通信-消息队列 kafka RabbitMQ RocketMQ

1. 这么多服务，如何管理

服务治理

服务注册与发现

• 基于客户端的服务注册与发现 Apache Zookeeper
• 基于服务端的服务注册与发现 Netflix Eureka

1. 服务挂了，怎么办

• 重试机制
• 服务熔断
• 服务降级
• 服务限流