您的位置 首页 golang

微服务业务架构的探索

原文:微服务业务架构的探索

提示

阅读这篇文章,需要有以下准备:

  1. 在微服务下挣扎过
  2. 需要了解DDD和COLA架构思想
  3. 本篇文章围绕业务架构进行讨论

前言

    公司在开始探索微服务架构时,使用的是三层架构(controller/service/model)。随着时间的推移,发现三层业务架构在微服务架构下越来越不适用,主要体现在下面2点:

  1. 业务逻辑离散在service层,不能很好的复用和表达能力差
  2. 业务代码和技术实现进行了强耦合,导致调试和测试困难

针对以上问题,我们开始探索新的业务架构,整理形成我们自己研发的业务框架:Esim (Make everything simple)。

回顾

此处输入图片的描述

    我对业务架构的思考,来自一道比较经典的面试题:什么是MVC?估计刚毕业的同学,都避免不了这道面试题。当然时间总是飞逝的,从毕业到现在,经历了PC时代,移动时代,到现在的微服务时代的技术变迁。技术的层出不穷,让我应接不暇。在回顾这个变迁的过程中发现一些比较有趣的事情,所以拿出来分享:

  • 架构一直在演进

    之所以用“演进”这个词,是因为新的架构思想需要一步一步形成,换句话说需要时间。我们以三层架构开始探索微服务,用了2年多,因为越来越痛苦才开始探索新的业务架构,但也花了1年多的时间,才有一个成形的框架。

  • 都是围绕模型,行为,数据进行变化

    自从把数据,模型,行为3兄弟从大杂烩解放出来后,他们就一直缠着你,这种纠缠很有可能伴随你的整个职业生涯。在PC时代,我们把3兄弟放到model里,所以当时有胖M,廋C的说法,有了经验后,在移动时代,我们把行为抽出来放到service,model留下数据和模型,再到现在的微服务时代,我们把行为和模型放到domain,数据放到了infrastructure。整个演进过程都围绕着这3兄弟。

  • 边界明显

    不同时代的的架构边界很清晰,PC时代说的是职责分离,移动时代说的是前后端分离,微服务时代说的是业务逻辑和技术分离。这些边界的出现和当时的环境脱不了关系。

事物脚本领域模型

使用过程来组织业务逻辑,每个过程处理来自表现层的请求。

事物脚本胜在简单,也正是简单,身边的很多同事也在使用相同的方式来组织代码,我自己也沉浸在里面很长时间,没有思考是否有更好的方式(需要吸取这个教训)。

在领域中合并了数据和行为的对象模型

领域模型强调的是组织业务逻辑前,先关注对象的行为,而事物脚本关注数据。

  • 例子

以我们最近重构的红包业务逻辑举个例看看他们之间的区别:只能在指定的洗车业务和A商家才能使用该红包。

事物脚本实现

couponService.go//是否满足红包使用条件func (cs CouponService) IsSatisfyUse(couponId int, bussinessType string, sellerId string) bool {    couponInfo := cs.CouponDao.FindById(couponId)    ......    couponConfInfo := cs.CouponConfigDao.FindById(couponInfo.ConfigId)    ......    //空代表所有业务都可以    if couponConfInfo.allowBussiness == "" {        return true    }        if bussinessType == "" {        return false    }        var allowBussiness bool    allowBussinesses := strings.Split(couponConfInfo.allowBussiness, ",")    for _, val := range allowBussinesses {        if bussinessType == val {            allowBussiness = true        }    }        if inBusiness == false {        return false    }        //空所有商家都允许使用    if couponConfInfo.allowSellers == "" {        return true    }        if sellerId == "" {        return false    }        var allowSeller bool    allowSellers := strings.Split(couponConfInfo.allowSellers, ",")    for _, seller := range allowSellers {        if sellerId == seller {            allowSeller = true        }    }        if allowSeller == true {        return true    } else {        return false    }}

    上面的代码就是比较典型的”一杆到底“,这样形式的代码在我们的系统很常见。
经常导致业务逻辑的代码不能很好的复用,业务逻辑分散在多个不同的方法或service文件里,很少有人能把他们慢慢找出来,
封装成共用方法。即使找到了又不敢轻易的把它们提取出来,因为它有可能和其他业务逻辑已经绑在了一起。

    当你抱着提升代码质量的情怀把它们提取出来,又因为没有很好的方法验证是否会影响了原有的业务逻辑。
导致出了很多次和原来预期对不上的问题(当时个个都坚信不会出问题),也让很多同学对自己产生了怀疑。
所以为了避免这些问题发生,我们通常对这些能复用的代码睁一只眼闭一眼,包括我自己。

领域模型的实现

coupon_service.go//是否满足红包使用条件func (cs CouponService) IsSatisfyUse(couponId int, bussinessType string, sellerId string) bool {    couponInfo := cs.CouponDao.FindById(couponId)    ......    couponConfInfo := cs.CouponConfigDao.FindById(couponInfo.ConfigId)    ......    if couponConfInfo.CheckAllowBusiness(bussinessType) == false {        return false    }      if couponConfInfo.CheckAllowSeller(sellerId) == false {        return false    }         return true}
entity/coupon_config.gotype CouponConfig struct {    id int         allowBussiness string        allowSellers string        ......}func (cc CouponConfig) CheckAllowBusiness(bussinessType string) bool {    //所有业务都可以    if cc.allowBussiness == "" {        return true    }        if bussinessType == "" {        return false    }        allowBussinesses := strings.Split(cc.allowBussiness, ",")    for _, val := range allowBussinesses {        if bussinessType == val {            return true        }    }        return false}func (cc CouponConfig) CheckAllowSeller(sellerId string) bool {    //所有商家都允许使用    if cc.allowSellers == "" {        return true    }        if sellerId == "" {        return false    }        allowSellers := strings.Split(cc.allowSellers, ",")    for _, seller := range allowSellers {        if sellerId == seller {            return true        }    }        return false}

    从上面的代码可以看出,我们把原来在coupon_service.go的业务逻辑都放到了实体coupon_config.go里面(行为和模型绑在了一起)。
业务逻辑不再离散,更内聚,能很好的复用,且写单元测试变得简单。

entity/coupon_config_test.gofunc TestEntity_CheckAllowSeller(t *testing.T)  {    testCases := []struct{        caseName string        sellerId string        allowSellers string        expected bool    }{        {"允许—空", "100", "", true},        {"允许2", "1", "1,100", true},        {"不允许", "1", "2,3,4", false},    }    for _, test := range testCases{        t.Run(test.caseName, func(t *testing.T) {            cc := CouponConfig{}            cc.allowSellers = test.allowSellers            result := cc.CheckAllowSeller(test.sellerId)            assert.Equal(t, test.expected, result)        })    }}

领域模型让我们写单元测试的时候不再关注所依赖的存储实现,让写单元测试这件事变得轻松、简单。

三层架构 到 四层架构

三层架构和四层架构一个明显的区别是业务和实现技术分离。

    在三层架构,业务和实现技术进行了强耦合,让开发在调试和测试时都要依赖真实的服务,导致浪费了很多时间在部署服务,造数据环节上,这个问题在微服务架构下更突出。四层架构可以很好的解决这个问题。还是以上面的代码为例(直接依赖了mysql):

coupon_service.go//是否满足红包使用条件func (cs CouponService) IsSatisfyUse(couponId int, bussinessType string, sellerId string) bool {    couponInfo := cs.CouponRepo.FindById(couponId)    ......    couponConfInfo := cs.CouponConfigDao.FindById(couponInfo.ConfigId)    ......        return true}

三层实现测试IsSatisfyUse(使用gorm的mock SDK):

coupon_service_test.gofunc TestCouponRepo_IsSatisfyUse(t *testing.T) {  cs := NewCouponService()  ......  couponReply := []map[string]interface{}{{"config_id": "100"}}  couonConfigReply := []map[string]interface{}{{"allow_bussinesses": "1,2", "allow_sellers" : "1,2"}}  Catcher.Attach([]*FakeResponse{        {            Pattern:"SELECT * FROM coupon WHERE",             Response: couponReply,             Once: false,         },        {            Pattern:"SELECT * FROM coupon_config WHERE",             Response: couonConfigReply,             Once: false,         },    })      result := cs.IsSatisfyUse(100, "1", "1")  assert.Equal(t, true, result)}

    上面的代码问题在于:如果业务代码依赖了某个技术实现,就要用对应的mock SDK来写单元测试。
只依赖一个mysql可能不会有太大问题,但技术发展到现在,业务逻辑基本不可能只依赖mysql。
还有可能是:redis,mongodb,http,grpc等,这说明你需要学习各式各样的mock SDk。
我当初就被这些海量的SDK,折腾的异常痛苦。也是这个原因才去寻找更好的办法:分离业务逻辑和技术实现。

四层实现 IsSatisfyUse(使用依赖倒置)

coupon_service.go//是否满足红包使用条件func (cs CouponService) IsSatisfyUse(couponId int, bussinessType string, sellerId string) bool {    couponInfo := cs.CouponRepo.FindById(couponId)    ......    couponConfInfo := cs.CouponConfigRepo.FindById(couponInfo.ConfigId)    ......    return true}infra/repo/coupon_repo.go//定义接口type CouponRepo interface {    FindById(int64) entity.Coupon}//db实现type DBCouponRepo struct {    couponDao *dao.CouponDao}func (dcr *DBCouponRepo) FindById(id int64) entity.Coupon {  ......  coupon, err = dcr.couponDao.Find("*", "id = ? ", id)  ......  return coupon}//coupon_config 同理

四层实现测试IsSatisfyUse(使用mockery SDK):

coupon_service_test.gofunc TestCouponRepo_IsSatisfyUse(t *testing.T) {  cs := NewCouponService()  ......  couponRepo := &mocks.CouponRepo{}  couponRepo.On("FindById", int64(100)).Return(entity.Coupon{ConfigId : 100})  cs.CouponRepo = couponRepo    couponConfigRepo := &mocks.CouponConfigRepo{}  couponConfigRepo.On("FindById", int64(100)).Return(entity.CouponConfig{AllowBussiness : "1", "AllowSellers" : "1"})  cs.CouponConfigRepo = couponConfigRepo    result := cs.IsSatisfyUse(100, "1", "1")  assert.Equal(t, true, result)}

    通过依赖倒置将具体的技术实现和业务分离,你将不再需要学习各式各样的mock SDK。
使用这种方式还有其他好处:

  1. 如果你要从mysql切换成其他存储层,只需要重新实现CouponRepo就可以了。不需要改动任何业务逻辑,且TestCouponRepo_IsSatisfyUse,还能正常使用。
  2. 使用接口分离技术实现,可以让你在开发过程不用关注依赖的服务是否可用,非常的便利。

结语

上面说了领域模型和四层架构的优点,我们来说说缺点:

  1. 有一定的学习成本

    有学习成本的一个原因是:现在大量的开发都是在使用事物脚本和三层架构做业务开发,要想转向领域模型和四层架构,
    需要花点时间(他们向工程师提了要求),但是如果转成功了,将会对公司的业务代码在测试性和扩展性上有很大的提升。

  2. 增加了一些繁琐工作

    四层比三层多了一些繁琐的文件创建:对每个资源都要提取接口和实现,依赖注入等,这些工作都很繁琐,所以我们才写了一个工具db2entity,把这些工作交由一个工具解决。

探索的过程可能很痛苦,但是探索出成果后会感到成就感,这估计就是探索的乐趣了,码农还需要前行。


文章来源:智云一二三科技

文章标题:微服务业务架构的探索

文章地址:https://www.zhihuclub.com/347.shtml

关于作者: 智云科技

热门文章

发表评论

您的电子邮箱地址不会被公开。

网站地图