微服务（五）

微服务（五）

向大佬学习的第五天 2020.4.26

为什么要做微服务

在说微服务之前、我们了解一下之前的高可用架构的样子

1、同一个项目部署多台服务器上、通过Nginx反向代理进行转发
架构痛点：
1、代码拷贝、重复性严重
对于用户数据来说、所有业务都使用同一份用户数据、而每个业务都维护了一份用户信息的DAO代码
2、复杂性扩散
对于用户数据来讲，如果我对用户数据进行的改造、或者加入缓存机制来提高数据库访问性能，那么在没有使用统一的服务层之前，每个业务都需要去关注用户的缓存机制。

对于用户数据的写请求，所有业务都需要升级代码：
1、清除cache
2、写入数据库
对于用户数据的读请求，所有业务都需要升级代码：
1、先读cache
2、没命中，再读数据库
3、把数据存入缓存
这个复杂性是典型的“业务无关的复杂性，业务方需要被迫升级
再者：当用户量很大的时候，需要进行数据库的水平拆分，引入分表分库，由于没有统一的服务层，各个业务层都需要关注分表分库引入的复杂性，这个复杂性也是跟”业务无关“

3、sql质量得不到保障、业务相互影响

当多个业务都去调用用户数据时候、SQL都是各个开发人员各自开发的，这里面就存在sql质量问题导致数据库性能受到不同程度的影响，
4、DB耦合

当业务不单纯操作用户数据、而是耦合各自的其他业务来操作数据库时，就会出现同一份用户数据跟各个业务的数据耦合，这样就导致每个业务也耦合在一起。

接下来要引入服务化来解决这些问题

最先想到的就是引入服务层，在业务层调用用户数据时、通过用户服务层进行统一管理
好处
1、调用方不需要再自己去组装sql、直接通过RPC调用用户服务层的方法获取即可
2、复用性、减少的代码拷贝
3、专注性、屏蔽底层复杂度
所有业务都不需要再关注用户数据结构变化、包括缓存、分表分库，只需要关注自己获取用户数据的方法即可
4、SQL质量得到保障
由专门的开发人员来进行用户数据库操作的sql编写
5、数据库解耦合
每个业务都只需要关注自己的业务数据库即可、不再通过join 来联查用户数据，讲用户数据库拆分出来。
6、提供有限接口、无限性能
当用户数据库到达瓶颈时、可以通过服务集群，一直提高性能

微服务的服务粒度选项

”粗粒度“粒度
所有基础数据的访问都通过一个service访问，但是当用户数据的业务非常复杂的时候，就会变得非常笨重，所以当用户业务会很复杂时，可以讲用户业务拆分成多个子业务进行开发。
”子业务系统“粒度作为微服务的单位


每个子业务都有一个自己的服务层、每个服务层互不影响、然后通过加入高可用服务分发层集群，并加入服务号的方式，减少依赖关系

说说RPC框架

RPC：（Remote Procedure Call Protocol）远程过程调用

以上是微服务架构的服务模型

以上是一个远程调用最基本的流程：
1、调用方传入参数、转成字节流进行发送、
2、服务方接收到字节流，调用本地函数、计算结果并返回
3、调用方接收字节流，转成参数
存在的问题：
1、调用方手动将参数转化成字节流（序列化）
2、调用方手动调用TCP传输字节流（网络传输协议）
3、调用方手动将字节流转换成参数（反序列化）

RPC框架职责：让你调用远程服务的方法就好像调用本地方法那么easy
整个RPC框架又分为client部分与server部分，负责把各类复杂性屏蔽，这些复杂性就是RPC框架的职责。

Client端包含：序列化、反序列化、连接池、负载均衡、故障转移、队列管理、超时管理、异步管理等
Server端包含：服务端组件、服务端收发包队列、io线程、工作线程、序列化反序列化、上下文管理器、超时管理、异步回调等