微服务基础知识小结

# 能不能说说什么是微服务架构

这个概念是在2014年，Martin Fowler和James Lewis共同提出的一套理论。微服务架构大概有一下几个特点:

微服务都是一个单一的小型服务，拥有自己的进程和轻量级处理。
服务根据业务功能进行划分设计，以全自动的方式完成部署，服务之间通过HTTP API的方式进行远程通信。
使用最小规模的集中管理技术，例如:Docker。
微服务可以使用不同的编程语言和数据。(这个目前似乎还没有实现)

# 微服务的架构的特征是什么

大抵来说有以下几点吧:

通过服务实现组件化:把服务当作组件使得其能够独立部署，其他服务接入时只需通过API来描述服务接口，一个服务可以通过RPC或者HTTP的方式进行通信。这样使得不同场景下某些服务是可插拔的。
根据业务划分团队:微服务架构之团队划分不再是传统的前后端这样划分，而是通过不同的服务进行划分开发团队。
去中心化(这点还没实现):不同服务可能使用不同的编程语言。
基础设施自动化:微服务中每个服务都需要独立部署，当服务量很大时，部署就不再像单体那样方便，所以持续集成和持续部署都是通用最佳实践了。
去中心化存储:微服务之下每个服务都有属于自己的数据库。

# 目前微服务存在那些问题呢

实现复杂度:从单体应用变成微服务，这个系统之间的调用就变得比较复杂。
服务之间调用变得复杂:服务都是独立进程，所以调用时可能通过HTTP和RPC进行调用，如何感知对端服务可用以及如果对端是集群的话，调用哪个服务的又如何决定也是个问题。
数据库一致性问题:不同服务之间就涉及到分布式事务问题。
微服务边界划分问题:如果服务划分过度，虽则业务复杂度上升，这个服务最终还是变成一个大单体，如果划分过细则会影响整个系统的性能。
对运维和开发都提出更高的要求:无论是开发还是部署难度都比单体要高很多。
开发流程复杂:按照业务拆分团队之后，一个功能的沟通可能相比过去会更加复杂。

# 进行微服务改造会面临那些挑战？

应用和数据库是紧耦的，可能一张数据表多个模块用到，或者一个模块用到了多张数据表。
表之间还是可能涉及JOIN等联查操作，很难划分代码和数据库的边界。
改造量大，可能存在风险。
需要所有业务团队进行配合改造。

# 如何对现有系统服务进行微服务改造

大抵需要以下几步:

圈表:按照业务维度将表圈在一起，确定服务的数据模型。
收集SQL语句:看看整个系统中，这张表在哪几处用到，将这些SQL语句收集起来，确定业务场景，使用频率。
拆分SQL语句:某些SQL语句可能会有JOIN操作，我们必须决定这种情况下还要不要拆，如果要拆要决定拆成怎样的SQL。
划分出独立数据库。
基于上述SQL，编写接口文档、代码开发、部署、测试。

# 能不能说说RPC和HTTP的区别

大抵有以下几点吧:

RPC主要用于系统内部服务调用，传输效率高（基于TCP，报文小），性能消耗低（高效的二进制传输、字节小、序列化耗时少），服务治理方便。HTTP是超文本协议，其包含的信息往往比较臃肿，网关之前一般用HTTP，服务之间能用RPC协议就用RPC协议，除非少部分情况，一些旧的服务它可能只支持HTTP。
传输协议：

RPC框架：可以基于HTTP协议，也可以基于TCP协议　　HTTP框架：基于HTTP协议

从网络协议来说，HTTP协议与RPC同属于应用层，他们的底层都是TCP协议。RPC（即Remote Procedure Call，远程过程调用）和HTTP（HyperText Transfer Protocol，超文本传输协议）他们最本质的区别，就是RPC直接通过自定义TCP协议实现通信，而HTTP服务需要通过HTTP协议，我们都知道HTTP协议是在传输层协议TCP之上的，所以相当于在中间又加了一层，从效率来看的话，RPC当然是要更胜一筹。

传输效率：

RPC：使用自定义的TCP协议，可以让请求报文体积更小，或者使用HTTP2协议，也可以很好的减小报文体积，提高传输效率　　HTTP：如果是基于HTTP1.1的协议，请求中会包含很多无用的内容，如果是基于HTTP2.0，那么简单的封装下可以作为一个RPC来使用，这是标准的RPC框架更多的是服务治理。

HTTP协议其实是属于面向桌面浏览器的一个通信协议，对于缓存，幂等或者Cookies相关的方面做了很多的事情。但是对于服务器之间直接的交互，RPC就能够体现出来他的优势了。自定义协议，减少数据传输：我们大概看一下HTTP协议。请求行，请求头部，请求数据，空行。很明显对于远程调用场景，我们对于请求行的依赖不是特别的强，那么这一部分在我们应用场景下，将会成为负担，但是http协议又是固定的，我们也不可能随便修改协议的格式。所以，通过rpc协议我们可以精简请求的数据，来尽可能少的传输我们的数据。当前，rpc也可以通过http协议来进行传输。