微服务架构是一种架构风格，它将一个大的系统构建为多个微服务的集合，这些微服务是围绕业务功能构建的，服务关注单一的业务功能，这些服务具有以下特点：
微服务架构能够快速、频繁、可靠地交付大型、复杂的应用程序，通过业务拆分实现服务组件化，使用组件进行组合从而快速开发系统。
我们首先进行微服务的划分，在实际的项目开发中，我们通常采用两种微服务划分策略，第一种方式是通过业务职能进行微服务边界的划分，第二种方式是通过DDD的界限上下文进行微服务边界的划分，我们这里采用大家比较容易理解的业务职能的方式进行微服务划分，再次贴上我们电商项目的思维导图：
从以上思维导图可以看出整个电商系统功能还是比较多的，我们根据业务职能做如下微服务的划分：
一般对客户端我们都会采用HTTP接口的方式提供服务，那是不是以上划分的这些微服务都需要直接提供HTTP接口对外提供服务呢？这样当然可以，架构整体看起来也比较简单。
但对于一个复杂的高并发的系统来说，我们需要处理各种异常的场景，比如某个页面需要依赖多个微服务提供的数据，为了避免串行请求导致的耗时过长，我们一般会并行的请求多个微服务，这个时候其中的某个服务请求异常的话我们可能需要做一些特殊的处理，比如提供一些降级的数据等。还有我们的页面展示的数据往往都是面向业务功能的，而不是单单某一个微服务的数据，这时候我们往往需要组装多个微服务的数据来满足需求，如果我们每个微服务都直接对外提供HTTP接口的话，那么这些复杂的数据组装和异常处理等工作只能由客户端来完成。众所周知客户端是不宜做复杂的业务逻辑的，客户端的重点应该更多是做交互体验上的优化，我们的整体架构需要做到前轻后重，即客户端逻辑尽量少而把比较重的业务处理逻辑下沉到服务端，而服务端又根据业务职能拆分成了不同的微服务，这些微服务只关注单一的业务，那么这些面向业务场景的复杂逻辑的处理应该放到哪里呢？我们的解决方案就是加一层，即BFF层，通过BFF对外提供HTTP接口，客户端只与BFF进行交互。
BFF层的引入解决了我们上面遇到的问题，但增加一层就会增加架构的复杂度，所以如果你的服务是一个单体应用的话，那么BFF是不必要的，引入它不会增加任何价值。对于我们这个项目来说，我们的应用程序依赖于微服务，同时我们需要面向业务功能提供HTTP接口和要保证接口的高可用，所以BFF对于我们这个项目来说是一个合适的选择。
我们可以提供多个BFF吗？答案是当然可以。BFF的目的是为客户端提供一个集中的接口，例如移动端页面和浏览器页面的数据协议不同，这种情况下为了更好的表示数据，可以使用两个BFF，同时只供一个BFF如果该BFF异常就会导致所有的业务受影响，提供多个BFF也可以提高服务的可用性，降低业务异常的影响面。多个BFF架构图如下：
我们的这个项目为了简化只会采用一个BFF服务。
我们采用集中管理的方式，把所有的服务放到一个大仓库中，仓库的目录结构如下：
lebron为工程名，lebron下面有apps和pkg两个目录，其中apps存放的是我们所有的微服务，比如order为订单相关的微服务，pkg目录为所有服务共同依赖的包的存放路径，比如所有的服务都需要依赖鉴权就可以放到pkg目录下。
在每个服务目录下我们又会分为多个服务，主要会有如下几类服务：
apps目录下每个服务的结构如下：
大多服务都会拆分成rpc、rmq和admin来满足对内提供rpc接口和运营数据的需求，同时通过rmq来处理流式任务。比较特殊的是app下只有api服务，因为app是BFF所有只有api服务，后面可能会增加rmq服务，比如来流式处理用户每天首次登陆加经验之类的逻辑，我们后面可以随时扩展，暂时先只提供api服务。recommend只有rpc服务，因为推荐服务需要依赖AI团队或者大数据团队提供的数据，我们只需要请求对应的数据接口和做一些满足业务的处理即可，所以这里recommend只有rpc服务。
整个工程的结构已经定义清楚了，下面我们做服务代码的初始化
我们使用goctl来进行项目的初始化，比如我们先初始化order，先进入order目录下：
$ cd lebron/apps/order
执行如下命令即可初始化order rpc代码
$ goctl rpc new rpc
生成的代码结构如下：
执行如下命令即可初始化order admin代码，注意order admin为api服务，直接对前端提供HTTP接口
$ goctl api new admin
生成的代码结构如下：
生成的服务代码我们可以直接运行，默认侦听在8888端口
$ go run admin.go
Starting server at 0.0.0.0:8888...
对于rmq服务我们会使用go-zero提供的 kq 功能，这里先初始化main.go
到这里order服务的代码初始化已经完成，其他服务和order服务类似，这里就不再赘述了。
pkg下目前不需要初始化，当我们需要提供业务通用功能的时候我们再进行添加。
本篇我们讲解了微服务的定义，微服务是围绕业务功能构建的，服务关注单一的业务，服务间采用轻量级的通讯机制，每个微服务都可以独立的部署和测试。
我们根据商城功能进行了微服务的拆分，主要拆分了购物车、订单、支付、商品、评论、推荐、账号等服务，然后我们又说明了为什么需要引入BFF服务，BFF本质上是一个用于做数据组装的服务，对外提供面向业务功能的或者说面向客户端UI的HTTP接口。
接着我们定义了我们这个工程的目录结构，主要分为api、rpc、rmq和admin等服务，不同服务的职责不同，api对外提供HTTP接口，rpc对内提供RPC接口，rmq做流式数据的处理，admin面向运营后台提供HTTP接口。
最后我们通过goctl对项目做了初始化，使用goctl可一键生成项目框架代码，大大提供了生产力。
希望本篇文章对你有所帮助，谢谢。
每周一、周四更新
代码仓库：https://github.com/zhoushuguang/lebron
https://microservices.io/index.html
https://blog.bitsrc.io/bff-pattern-backend-for-frontend-an-introduction-e4fa965128bf
https://github.com/zeromicro/go-zero
https://gitee.com/kevwan/go-zero
欢迎使用 go-zero 并 star 支持我们！
关注『微服务实践』公众号并点击 交流群 获取社区群二维码。
微信关注我们
转载内容版权归作者及来源网站所有！
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。
马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。
为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。
Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称，一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。
扫码在手机上查看文章
扫描二维码，手机阅读更方便
有任何问题或合作意向欢迎联系我们
Email: 99873273@qq.com
QQ: 99873273