cola 微服务业务架构的探索

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



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



不同时代的的架构边界很清晰，PC 时代说的是职责分离，移动时代说的是前后端分离，微服务时代说的是业务逻辑和技术分离。这些边界的出现和当时的环境脱不了关系。 事务脚本到领域模型 什么是事务脚本 使用过程来组织业务逻辑，每个过程处理来自表现层的请求。 事务脚本胜在简单，也正是简单，身边的很多同事也在使用相同的方式来组织代码，我自己也沉浸在里面很长时间，没有思考是否有更好的方式（需要吸取这个教训）。 什么是领域模型 在领域中合并了数据和行为的对象模型 领域模型强调的是组织业务逻辑前，先关注对象的行为，而事务脚本关注数据。 例子 以我们最近重构的红包业务逻辑举个例看看他们之间的区别：只能在指定的洗车业务和 A 商家才能使用该红包。

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.go type CouponConfig struct {

id int 



allowBussiness string



allowSellers string



...... }

if bussinessType == "" {

    return false

}



allowBussinesses := strings.Split(cc.allowBussiness, ",")

for _, val := range allowBussinesses {

    if bussinessType == val {

        return true

    }

}



return false }

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.go func 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)

    })

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

return true } 三层实现测试IsSatisfyUse（使用 gorm 的mock SDK）： coupon_service_test.go func 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, 

    },

})