学习微服务｜从认识开始

学习微服务从以下几个问题开始入手，逐步了解微服务、使用微服务：

• 什么是微服务
• 使用微服务的判断
• 微服务框架

单体应用

微服务之前先说下单体应用。我最开始接触的单体应用是生产进销 ERP 系统，模块很多且业务逻辑复杂。项目中涵盖了从合同管理、订单、物料进销存、产品进销存、财务、物资管理等模块。不仅业务规模不断扩大而且不同客户业务也不同。整个开发成本也变大，代码膨胀，每次服务部署时因依赖资源多，编译打包部署都要经历很长的时间。更不用说系统的性能问题啦。

单体应用在遇到企业级应用时基本的痛点是：部署效率低，团队协作成本高、项目臃肿、甚至存在很大高可用性差的问题。

解决的方案就是：服务化。就是将各模块从单体应用中独立成一个服务，专门人员开发和维护。

因容器化技术的成熟，服务化思想进一步演化：微服务。

微服务

服务化是将单体应用根据模块进行独立成一个服务，微服务是更细粒度的服务化，拆分出来的服务独立部署和维护。比如ERP合同模块中又有合同管理模块、审批流模块、权限模块。这些可以进行独立各组维护。但其中审批流发生变化时仅修改审批流模块然后发布，其他模块都不影响。

所以个人理解，微服务是对模块更细粒度的划分，且服务治理能力要求更高，独立部署、维护。拆分很多服务后就需要一个统一的服务治理平台对服务进行管理。

拆分服务

拆分微服务基本就三种方式：

• 纵向：以业务角度，按模块进行划分。相对独立的业务单独拆分成一个微服务，关联密切的业务拆成一个微服务。
• 横向：以功能角度，根据公共且独立的功能纬度进行拆分，公共的功能被其他服务调用，且不与业务耦合
• 根据实际业务场景，可以纵向和横向相结合

拆分服务肯定是要依据自己的实际场景，考虑团队规模和服务的复杂度进行拆分。之前看到技术大佬建议可以按照开发人员总人数进行决定拆分服务数量，开发人员应当负责不超过3各大服务为标准。

微服务架构

整个过程基本可以分三个角色：服务提供者、服务调用者、注册中心。微服务架构下，服务调用主要依赖依赖以下几个基本组件：

• 注册中心

服务提供者提供服务，向注册中心注册服务，声明自己提供服务地址，提供什么服务的描述；服务调用者请求注册中心，查询要调用的服务地址，并按约定协议发起请求获取结果。

注册中心还需提供功能：监控服务提供者，当服务发生变化就会将变更通知给调用者。

在 Kratos 框架中提供了注册中心的组件且已经支持consul、discovery、etcd、nacos等注册中心组件。从 Kratos 官网文档中可以看到起提供的注册和获取服务的接口

// 服务注册
type Registrar interface {
    // 注册实例 -- 进行服务注册
    Register(ctx context.Context, service *ServiceInstance) error
    // 反注册实例-- 进行服务注销
    Deregister(ctx context.Context, service *ServiceInstance) error
}
// 服务发现
type Discovery interface {
    // 根据 serviceName 直接拉取实例列表
    GetService(ctx context.Context, serviceName string) ([]*ServiceInstance, error)
    // 根据 serviceName 阻塞式订阅一个服务的实例列表信息
    Watch(ctx context.Context, serviceName string) (Watcher, error)
}

注册中心其实还需要服务监控，即服务心跳检测保证服务实时有效。当然还需要一个可以直接对服务查询和修改的接口。

• 服务描述：服务提供者需对外描述其所提供的是什么服务，需要的条件，返回的结果格式。基本常用的描述方式：RESTful API、XML配置以及IDL文件。
• 服务框架：服务调用者从注册中心查询到对应的服务地址，就可以根据服务描述采用相应的协议，数据传输方式和数据传输格式进行调用。
• 服务监控和服务追踪：服务调用的过程中，会记录、监控各种调用过程和链路以便出现问题时方便故障定位和问题追踪。
• 服务治理：服务监控可以发现问题，服务追踪可以定位问题，解决问题还得靠服务治理。