微服务架构
一、前期概要
微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。
主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
要理解微服务，首先我们先理解跟微服务相对的是单体应用，所谓的单体应用所有功能都打包成在一个独立单元的应用程序。从单体应用到微服务并不是一蹴而就的，而是一个逐渐演变的过程。
二、架构演进
1、单体应用
image
优点：
-
开发简单，集中式管理
-
基本不会重复开发
-
功能都在本地，没有分布式的管理和调用消耗
缺点：
-
效率低：开发都在同一个项目改代码，相互等待，冲突不断
-
维护难：代码功功能耦合在一起，新人不知道何从下手
-
稳定性差：一个微小的问题，都可能导致整个应用挂掉
-
扩展性不够：无法满足高并发下的业务需求
存在的问题:
-
Tomcat和数据库之间竞争资源，单机性能不足以支撑业务
-
随着用户数的增长，并发读写数据库也成为瓶颈
2、应用与数据库单独部署引入缓存
image
说明:
在服务器上加入缓存，缓存热数据。通过缓存能把绝大多数请求在读写数据库前拦截掉，大大降低数据库压力。主要使用使用Redis作为缓存数据库，但同时也会带来一些问题例如 、缓存穿透/击穿、缓存雪崩等一系列问题
存在的问题:
- 缓存抗住了大部分的访问请求，但并发压力主要落在单机的Tomcat上，响应越来越变慢
3、应用集群与负载均衡
image
特点
-
对 Java 应用程序进行独立部署，形成 应用集群；
-
数据库 进行独立部署；
-
Web 集群 与 应用集群 间通过 HTTP 协议进行交互；
-
应用集群 与 数据库 间通过 JDBC 协议进行交互。
4、移动端出现与前端分离
image
随着系统访问量的持续增加，面对大量的数据读取请求，数据库有些不堪重负。
image
特点
-
对数据库实施 主从 部署策略；
-
对于数据的写请求，只能在 主库 上进行；
-
对于数据的读请求，可以在任意的 从库 上进行；
-
主库与从库间，通过 数据库同步策略 进行数据同步。
问题
- 业务逐渐变多，不同业务之间的访问量差距较大，不同业务直接竞争数据库，相互影响性能
5、应用垂直拆分
随着业务的增长应用越来越大我们可以将其进行拆分，将其拆分为多个应用，每个应用独立开发、独立部署、独立维护。
image
特点
-
通过不同的域名或URL将整个系统分解为多个子系统；
-
用户通过浏览器将各子系统拼接成一个完整的系统；
-
各系统间存在少量交互，甚至没有交互；
存在的问题
问题慢慢展现出来，系统间公共部分没有统一维护点，同样的功能、同样的代码分布在各个系统中。
6、服务化架构
通用功能封装成一个服务，独立开发、独立部署、独立维护。将业务逻辑进行了进一步拆分
-
整理各个系统间通用业务功能，将其封装为服务，以承载核心业务逻辑，构建成 服务集群；
-
原来的子系统或子频道，变成薄薄的一层，不承载核心业务，只是根据业务流程对业务服务进行编排；
-
应用服务与业务服务间通过 HTTP 或其他协议进行通信，常见的包括 Dubbo、gRPC、Motan等
image
三、概念说明
-
分布式
系统中的多个模块在不同服务器上部署，即可称为分布式系统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上
-
集群
一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。如Mysql中的Master和Slave分别部署在多台服务器上，共同组成一个整体提供集中配置服务。在常见的集群中，客户端往往能够连接任意一个节点获得服务，并且当集群中一个节点掉线时，其他节点往往能够自动的接替它继续提供服务，这时候说明集群具有高可用性
-
高可用
系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性
-
负载均衡
请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的
-
反向代理
系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程。
参考
