基于GRPC+consul通信的服务化框架

—.背景

谈论服务化框架的时候，我们首先先了解这些概念：SOA、ESB、OSGi、servicemix、微服务、Spring Boot

SOA:面向服务架构，传统简单的网站系统采用MVC架构,随着系统需求不断的变化和业务不断的扩展，MVC显得很无力，MVC不断的变大，维护开发越来越困难，SOA解决的是MVC里面大而核心的功能，抽离出来做成服务提供给不断变化的业务使用。SOA提出多年，它仅仅是一个概念—一切皆服务，并不是一种技术的实现。

ESB:企业服务总线，是SOA 其中一种实现，打个比方，电商SOA包含会员、商品、支付、短信、物流等服务，比如用户购买商品需要整合下面服务，登录—>下单—>支付—>物流，ESB正是解决这种服务消息之间的路由规则,因此称之为服务总线。

OSGi:面向java动态系统，它的基础是动态化，目的是模块化，目标是系统解耦。电商系统中：我们可以抽离支付为一个模块，短信为一个模块，用户一个模块、产品一个模块,这样拆分大系统,降低耦合,强调了一切皆模块。

serviceMix:是apache下面一个支持OSGI的ESB容器，与普通的tomcat相比，tomcat运行的一个war包，serviceMix运行的是一个bundle（实质是jar包）；tomcat不能动态增删模块，serviceMix是可以；tomcat的war包之间不能调用，serviceMix可以引用同一个容器的bundle服务。

微服务:功能单一的服务，是相对与SOA的一种说法，SOA是胖服务，集成了整个系统所有的服务，而微服务强调微小，一个服务最好只做一件事。比如签到微服务，短信微服务，它与OSGi目的都是一样。

Spring Boot:微服务的一种实现及其运行方式，采用了优秀spring，但是剔除了繁琐的XML配置，内嵌tomcat或者jetty等容器，极其简单开发部署。

二.服务化引入

网站系统随着不断的发展，越来越复杂，架构的变迁也会从MVC—>SOA—>微服务,从简单到复杂，从集中到分布，上面介绍的技术都是为了解决这些问题。服务化框架的引入是SOA—>微服务过程必须要解决的问题。面对服务的增多，服务分布的部署，服务与服务之间相互的调用，不得不使用服务化框架去解决。著名的dubbo就是这样产生的。

三.服务化框架的简介

服务化框架分为两部分：rpc、注册中心

1.rpc:远程调用，远程调用的传输协议有很多种，可以走http、webservice、tcp等。facebook的thrift、google的grpc、alibaba的dubbo世界上主流的rpc框架。其重点在于安全、快速、最好能跨语言。

2.注册中心:用于存放，服务的ip地址和状态信息等。比较好的存放服务信息的方案有:zookeeper、consul、redis。其重点在于避免单点问题，并且好维护。

四.服务化框架原理

根据上面图，服务化原理可以分为3步：

1.服务端启动并且向注册中心发送服务信息，注册中心收到后会定时监控服务

2.客户端需要开始调用服务的时候，首先去注册中心获取服务信息

3.客户端创建rpc连接，服务端返回处理信息

第3步又可以细分，下面说说rpc的原理：

目标：客户端C类怎么调用远程机器上S服务的a.say()方法

1）.服务发现，向注册中心获取服务(这里需要做的有很多：拿到多个服务时需要做负载均衡，同机房过滤、版本过滤、服务路由过滤等)

2）.客户端发起调用，将需要调用的服务和方法和参数进行组装

3）.序列化编码组装的消息，这里可以使用json，也可以使用xml，也可以使用protobuf，也可以使用hessian，几种方案的序列化速度还有序列化后占用字节大小都是选择的重要指标。

4）.传输协议，可以使用传统的io阻塞传输，也可以使用高效的nio传输(netty)。

5）.服务端收到后进行反序列化，然后进行相应的处理。

6）.服务端序列化response信息并且返回。

7）.客户端收到response信息并且反序列化。

五.服务化框架实现

以上介绍了服务化框架基本信息和原理。下面介绍服务化框架的实现。

选取一种注册方案，鉴于zookeeper坑太多，偏向于选择consul，consul不像zookeeper这么抽象，封装了服务化的http api，非常方便调用，并且增加了对服务健康检查。选取一种rpc方案，对比thrift和grpc，结合两者的特性，grpc支持android ios app调用，功能更加强大，并且基于http2传输，多路复用，并发情况不需要创建多个线程进行管理，并且是使用的protobuf3进行序列化，高效快捷。

以上的方案选取好后，就可以进行代码实现了。