微服务 – Go语言从单体服务到微服务(设计方案篇)

概述

微服务是一种思维，与编程言语无关，编程言语是思维下具体的一种完成方法，怎样规划架构计划和完成首要看首要面对的业务场景。

业务场景

主站中心业务运用的是yaf(php)开发的，要完成k8s + x编程言语 自主微服务完成，受到陈皓(左耳听风)的影响，我选用的编程言语是Go，Go言语有更强大的生态，有谷歌，k8s作为强大的后台，摸着石头过河。

规划计划

Api网关

说到微服务我们就联想到Rpc，主流微服务价格规划，微服务之间的调用都运用Rpc，微服务也有直接用http完成的，Rpc约束了开发时分的灵活性和兼容性，首要3点原因:

1.Http协议是实际通讯的规范，灵活性和兼容性得到了很好的商场验证，对Rpc我抱有怀疑态度，在Api层进行权限的一致认证( Token/Cookies ) , 后期微服务体系成熟，能够一致接入Api网关服务，Api网关服务是不可缺少的，全运用Nginx反向署理的方法，再数据计算的角度上局限性。

2.操控反常，如果发生反常,Rpc服务挂掉或许遭到网络攻击/刷恳求，恳求会直接打到Rpc上，如果有网关层，能够在Redis中加Redis锁，把无效的网络恳求进行阻隔。

数据

拆分微服务最大的两个问题是数据的一致性和功用，体系功用的瓶颈首要是因为计算机Cpu，内存(memory/内存条、cache/Cpu的内存) 是十分快的，所有的功用问题迥然不同，磁盘I/O往往才是功用的瓶颈。

1.数据的一致性的解决办法

模块化拆分和迁移微服务功用，把涉及到的整块进行迁移，能够按比重分流/整体功用进行，按比重分流要保留新旧数据的兼容，需求双写，现在的有声业务体量小，能够整块整块的迁移。

2.功用：有声的数据量十分小，暂时不运用redis缓存或许也不会造成什么功用问题，所以我把很小的公共部分进行了缓存，首要考虑C端用户的体会。

Go中的Grpc运用

Go-zero这个结构运用goctl东西开发速度十分高效，对调用外部的Grpc服务需求做更多的兼容，这儿做一个解释说明，protoc-gen-go、protoc-gen-go-grpc这两个东西是protobuf的东西，是Go 1.5版别后新加的，这个当地饶了好大一圈。

GitHub Demo 地址 : github.com/grpc/grpc-g…

$ go install google.golang.org/protobuf/cmd/protoc-gen-go@v1.28
$ go install google.golang.org/grpc/cmd/protoc-gen-go-grpc@v1.2

在有声微服务中，是调用UserRpc的权限验证部分，Go-zero不支持，所以自己写了一些兼容包。

1.首先pb文件生成Pb和Grpc文件

$ ll
-rw-r--r--  1 stark  staff    69K  3 20 15:51 cp_user_internal.pb.go
-rw-r--r--  1 stark  staff    34K  3 20 15:51 cp_user_internal_grpc.pb.go

2.调用UserRpc服务,需求完成的包是客户端部分代码，本地需求TLS加密，服务才干被调用的到,grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{})))是TLS魂灵。

package client
func Auth(Session string, Action string, Controller string, Param string) bool {
    // 1.建立链接
    flag.Parse()
	conn, err := grpc.Dial("testing.gongzicp.com:1443", grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{})))
	if err != nil {
		log.Fatalf("did not connect: %v", err)
	}
	defer conn.Close()
	client := pb.NewUserInternalClient(conn)
	//2.验证管理员权限
	resp, err := client.AdminMid(context.Background(), &pb.UserInternalParams_AdminMidReq{
		Session: Session,
	})
	//3.验证菜单权限
	auth, err := client.AdminAuth(context.Background(), &pb.UserInternalParams_AdminAuthReq{
			Action:     Action,
			Controller: Controller,
			Param:      Param,
			Session:    Session,
		})
	//....
}

问题和反思

1.有声服务和主站的相关十分小,可是也有相关NovelId获取信息的部分，Novel属于中心服务，或许每一个当地的需求都不少。

2.Web端(Ukey) 、App安卓/Ios(Token) 本质上是一个维度的东西，类型上应该只用户/和体系管理员2种类型，最好是把服务类抽离出来做成独自的服务，或许会更好一些。