一. 简单初步认识微服务

一：什么是微服务？为什么要用微服务？

（一）什么是微服务？

　　简单举例：看军事新闻的同学应该都知道，一艘航空母舰作战能力虽然很强，但是弱点太明显，就是防御能力太差，单艘的航空母舰很少单独行动，通常航空母舰战斗群才是主要军事力量，你可以把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务。

　　大部分的开发者经历和开发过单体应用，无论是传统的 Servlet + JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构？个人总结主要问题如下：

• 部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）
• 改动影响大，风险高（不论代码改动多小，成本都相同）
• 因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）

 

（二）微服务的特点：

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

• 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。

• 面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。

• 自治：自治是说服务间互相独立，互不干扰

• 团队独立：每个服务都是一个独立的开发团队，人数不能过多。

• 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉

• 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口

• 数据库分离：每个服务都使用自己的数据源

• 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

 

（三）微服务架构图：

 

　　

 

　　

 

二：服务的调用方式

　　Dubbo架构的服务调用主要是基于Dubbo协议的RPC调用。　　

　　SpringCloud的服务调用是基于Http协议的Rest风格调用。两者存在较大的差异。

　　虽然Dubbo协议和Http协议都是基于TCP的传输层协议，但Http协议设计的初衷是基于页面访问（超文本传输），因此两者的数据传输格式存在较大的差异。

　　

Ⅰ.Http协议

（一）HTTP请求包括：请求行、请求头、请求体等信息：

• 请求行：包含请求的资源路径，例如 /user/init/1，是判断要调用的目标方法的重要信息

• 请求头：包含

  • host信息，例如：192.168.0.10:8600，决定了要调用的目标服务器的地址

  • content-type信息：例如 application/json，决定了请求参数的格式

  • accept信息：例如application/json，决定了接收的响应格式信息

  • 其它略。。

• 请求体：包含请求参数信息

 

（二）当调用者发出一个http请求时流程如下：

　　

 

可以看到请求参数是由tomcat接收并解码处理的，而我们的java程序只需要负责根据请求path，找到对应的HandlerMethod并调用即可。

其好处包括：

• 可以简化我们的开发

• 调用者与服务提供者完全解耦，只要能发送或处理http请求即可

但缺点也很明显：

• 请求参数编解码过程是tomcat处理，性能完全由tomcat性能来决定，难以进一步优化。

• 请求参数格式固定，有很多冗余数据，略显臃肿，并在一定程度上会影响传输性能

 

Ⅱ.Dubbo协议

（一）Dubbo协议的调用过程如下图：

调用者需要对请求参数做编码、数据做序列化。被调用者需要对数据做反序列化、头信息做解码，然后完成请求分发和调用。其中数据传输消息格式完全由Dubbo协议自己定制，比较精简。

（二）数据消息格式主要包括：

• 消息头：用于存储一些元信息，比如魔数（Magic），数据包类型（Request/Response），消息体长度（Data Length）等。

• 消息体：用于存储具体的调用消息，比如版本号、接口名、方法名称、参数类型、参数值等。

（三）服务调用者的调用步骤包括：

• 服务调用者与服务提供者建立连接

• 服务调用者准备请求消息（包括消息头和消息体）

• 服务调用者编码消息，并完成消息序列化

• 服务调用者传递消息到提供者

• 提供者解码消息，获取被调用的接口名、方法名、参数类型、参数值等信息

• 找到要调用的方法，派发线程去执行并得到结果

• 将结果封装为标准消息格式

• 序列化响应消息，并传输给调用者

 

可以看出，Dubbo调用的请求发送、接收、消息的编解码都是由Dubbo框架来实现的。因此消息具备下列优缺点。

优点：

• 请求连接基于Netty框架，是高性能的网络框架

• 请求消息格式由Dubbo定义，简洁高效

• 消息序列化方式多样化，可定制高效的序列化方式，性能有优势

缺点：

• 调用者和提供者者都要使用Java语言

• 提供者需要对外暴露自己的service接口，耦合度高