SpringCloud (一) :微服务架构

什么是微服务架构

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

( 单体架构 )

单体架构

( 微服务架构 )

微服务架构

  微服务架构优点

解决了代码臃肿的复杂问题。它把可能会变得庞大的单体应用程序分解成一套服务。虽然功能数量不变,但是应用程序已经被分解成可管理的块或者服务,个体服务能被更快地开发,并更容易理解与维护。

分割明确,使得保持团队之间的界限变得容易。微服务架构使整个系统的分工更加明确,责任更加清晰,每个人专心负责为其他人提供更好的服务。在单体应用的时代,公共的业务功能经常没有明确的归属。最后要么各做各的,每个人都重新实现了一遍;要么是随机一个人做到他负责的应用里面。

服务可以独立部署。如果你的应用由单个进程中的多个库组成,则对单个组件的任何更改都将导致不得不重新部署整个应用。但是,如果将应用分解为多个服务,你可以期望单个服务的更改只需要重新部署该单个服务即可。

微服务架构缺点

微服务架构整个应用分散成多个服务,定位故障点非常困难。

稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大,并且一个服务故障可能导致整个系统挂掉。事实上,在大访问量的生产场景下,故障总是会出现的。

服务数量非常多,部署、管理的工作量很大。

服务拆分后,几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。

 

微服务架构四大问题

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

通过API网关

服务与服务之间如何通信

同步通信-HTTP/RPC

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

这么多服务,如何管理

服务治理

服务注册与发现

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

基于服务端的服务注册与发现 Netflix Eureka

服务挂了,怎么办

重试机制

服务熔断

服务降级

服务限流

 

我的个人博客站

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zywfxx.html