微服务（micro services）

微服务概述

微服务简介

• 微（micro）狭义来讲就是体积小，著名的"2 pizza 团队"很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。

• 服务（service）区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集

从广义上来讲，微服务是一种分布式系统解决方案，推动细粒度服务的使用，这些服务协同工作

微服务架构

微服务架构风格是将单个应用程序作为一组小型服务开发的方法，每个服务程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务是围绕业务功能构建的。可以通过全自动部署机器独立部署。这些服务器可以用不同的编程语言编写，使用不同的数据存储技术，并尽量不用集中式方式进行管理

• 微服务架构是将复杂的系统使用组件化的方式进行拆分，并使用轻量级通讯方式进行整合的一种设计方法。

• 微服务是通过这种架构设计方法拆分出来的一个独立的组件化的小应用。

微服务架构定义的精髓，就是“分而治之，合而用之”。

• 将复杂的系统进行拆分的方法，就是“分而治之”。分而治之，可以让复杂的事情变的简单

• 使用轻量级通讯等方式进行整合的设计，就是“合而用之”的方法，合而用之可以让微小的力量变动强大

服务拆分原则：高内聚低耦合

微服务和单体架构

单体架构的问题和缺陷

• 复杂性逐渐变高：代码越多复杂性越高，越难解决遇到的问题

• 技术债务逐渐上升：人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多

• 耦合度太高，维护成本大

• 持续交付周期长

• 技术选型成本高：单块架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大

• 可扩展性差：随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展

微服务架构的解决方案

单一职责

微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。

轻量级通信

服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式。

• 对于轻量级通信的格式而言，例如 XML 和 JSON，它们是语言无关、平台无关的

• 对于通信的协议而言，通常基于 HTTP，能让服务间的通信变得标准化、无状态化

使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。

独立性

每个服务在应用交付过程中，独立地开发、测试和部署

在单体式架构中：所有功能都在同一个代码库，功能的开发不具有独立性；当不同小组完成多个功能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用被构建成一个包，如果某个功能存在 bug，将导致整个部署失败或者回滚

在微服务架构中：每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署

进程隔离

单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署。

在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上。

微服务架构的缺陷

1. 运维要求高，难度大

2. 分布式的复杂性，导致bug不好调试

3. 接口成本高：一旦微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口造成的成本会很高。

4. 重复劳动：对于单体架构来讲，如果某段业务被多个模块所共同使用，便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

5. 业务不好分离

单体架构和微服务架构的对比

RPC协议

RPC概述

RPC(Remote Procedure Call Protocol)，是远程过程调用的缩写，通俗的说就是调用远处的一个函数

使用微服务化的一个好处就是，不限定服务的提供方使用什么技术选型，能够实现公司跨团队的技术解耦，如下图：

这样的话，如果没有统一的服务框架（RPC框架），各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动，造成整体的低效。所以，统一RPC框架把上述“业务之外”的技术劳动统一处理，是服务化首要解决的问题。

go语言中使用RPC

Go语言的RPC规则：方法只能有两个可序列化的参数，其中第二个参数是指针类型，并且返回一个error类型，同时必须是公开的方法。

golang 中的类型比如：channel（通道）、complex（复数类型）、func（函数）均不能进行 序列化

Server端

 func main(){
     // rpc注册服务, 注册rpc服务，维护一个hash表，key值是服务名称，value值是服务的地址
     rpc.RegisterName("HelloService", new(HelloService))
 ​
     // 设置服务监听
     listener,err := net.Listen("tcp","127.0.0.1:8888")
     if err != nil {
         panic(err)
     }
 ​
     // 接受传输的数据
     conn,err := listener.Accept()
     if err != nil {
         panic(err)
     }
 ​
     // rpc调用,并返回执行后的数据
     //    1.read，获取服务名称和方法名，获取请求数据
     //    2.调用对应服务里面的方法，获取传出数据
     //    3.write，把数据返回给client
     rpc.ServeConn(conn)
 }

1. rpc.Register函数调用会将对象类型中所有满足RPC规则的对象方法注册为RPC函数，所有注册的方法会放在“HelloService”服务空间之下

2. 然后建立一个唯一的TCP链接，并且通过rpc.ServeConn函数在该TCP链接上为对方提供RPC服务

Client端

 func main(){
     //用rpc连接
     client,err := rpc.Dial("tcp","127.0.0.1:8888")
     if err != nil {
         panic(err)
     }
 ​
     var reply string
     //调用服务中的函数
     err = client.Call("HelloService.Hello","world",&reply)  // 这里的HelloServer就是Server注册的服务名，然后Hello就是这个服务下的Hello方法
     if err != nil {
         panic(err)
     }
 ​
     fmt.Println("收到的数据为,",reply)
 }

• 首选是通过rpc.Dial拨号RPC服务，然后通过client.Call调用具体的RPC方法

• 在调用client.Call时，第一个参数是用点号链接的RPC服务名字和方法名字，第二和第三个参数分别定义RPC方法的两个参数。

跨语言的RPC

RPC协议封装

未封装的代码服务名都是写死的，不够灵活，且容易写错，所以这里对RPC的服务端和客户端再次进行一次封装，来屏蔽掉服务名。

服务端封装

 package main
 ​
 import (
     "fmt"
     "net"
     "net/rpc"
     "net/rpc/jsonrpc"
 )
 ​
 var ServiceName = "login"
 ​
 // 定义一个接口，作用是限定我们自己定义的RegisterRPC函数的参数类型，以及它要实现的方法
 type RPCDesign interface {
     Say(string, *string) error
 }
 ​
 // 定义要注册到RPC的类和方法，这里Persion实现的了Say方法，所以它可以作为RegisterRPC的参数
 type Person struct{}
 ​
 func (p *Person) Say(in string, out *string) error {
     *out = in + "hahahahahaha"
     return nil
 }
 ​
 // 把RPC的注册方法再封装一层
 func RegisterRPC(srv RPCDesign) error {
     return rpc.RegisterName(ServiceName, srv)
 }
 ​
 func main() {
     // 设置监听
     Listener, err := net.Listen("tcp", "127.0.0.1:9999")
     if err != nil {
         fmt.Println("listen failed, err: ", err)
         return
     }
     defer Listener.Close()
     fmt.Println("Start Listening...")
 ​
     for {
         // 开始接受连接
         conn, err := Listener.Accept()
         if err != nil {
             fmt.Println("connection err: ", err)
             return
         }
         defer conn.Close()
         fmt.Println(conn.RemoteAddr().String() + "connect success.")
 ​
         // 注册RPC
         err = RegisterRPC(new(Person))
         if err != nil {
             fmt.Println("Regist RPC failed, err: ", err)
             return