微服务架构基础_1

单体架构
单体架构是早期的架构模式。单体架构将所有业务场景的表示层，业务逻辑层和数据访问层放在同一个工程中，最终经过编译，打包，并部署在服务器上。

比如，经典的 J2EE 工程，它就是将表示层的 JSP、业务逻辑层的 Service、Controller 和数据访问层的 DAO（Data Access Objects），打包成 war 文件，然后部署在 Tomcat、Jetty 或者其他 Servlet 容器中运行。

互联网产品的普及，承载流量越来越大，单体架构缺点：

灵活性差： 无论多小的改动，都要打包整个应用
可扩展性差： 高并发场景下，无法一模块为单位扩容
稳定性差： 任何一个模块有问题，都可能整个应用不可用
可维护性差： 业务复杂性提升，项目整体维护性差

微服务架构诞生
基于单体架构的局限性，微服务架构诞生。

一个复杂的系统由一系列独立的微服务组成，各个微服务运行在自己独立的容器中，开发和部署都没有依赖。

微服务架构特点：

• 每个服务运行在其独立的进程中，开发采用的技术栈也是独立的；
• 服务间采用轻量级通信机制进行沟通，通常是基于 HTTP 协议的 RESTful API；
• 每个服务都围绕着具体的业务进行构建，并且能够被独立开发、独立部署、独立发布；
• 对运维提出了非常高的要求，促进了 CI/CD 的发展与落地。
  
  微服务架构实践
  客户端如何访问这些服务
  每个服务之间如何通信
  如此多的服务如何实现
  服务挂了，如何解决

客户端如何访问这些服务

一般在后台N个服务和UI之间一般会一个代理或者叫API 网关，其作用有下：

①提供统一服务入口，让微服务对前台透明

② 聚合后台的服务，节省流量，提升性能

③ 提供安全，过滤，流控等API管理功能

gateway为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。

微服务架构需要考虑：

1、API Gateway

2、服务间调用

3、服务发现

4、服务容错

5、服务部署

6、数据调用

如图：

每个服务之间如何通信

同步调用：

①REST（JAX-RS，Spring Boot）

②RPC（Thrift, Dubbo）

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候

异步消息调用(Kafka, Notify, MetaQ)

而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的

服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息

发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）

服务挂了，如何解决

①重试机制

②限流

③熔断机制

④负载均衡

⑤降级（本地缓存）