共计 3124 个字符，预计需要花费 8 分钟才能阅读完成。
微服务概述
微服务架构是一种架构格调，它将一个大的零碎构建为多个微服务的汇合，这些微服务是围绕业务性能构建的，服务关注繁多的业务性能，这些服务具备以下特点：
- 高度可保护和可测试
- 涣散的耦合
- 可独立部署
- 围绕业务性能进行构建
- 由不同的小团队进行保护
微服务架构可能疾速、频繁、牢靠地交付大型、简单的应用程序，通过业务拆分实现服务组件化，应用组件进行组合从而疾速开发零碎。
服务划分
咱们首先进行微服务的划分，在理论的我的项目开发中，咱们通常采纳两种微服务划分策略，第一种形式是通过业务职能进行微服务边界的划分，第二种形式是通过 DDD 的界线上下文进行微服务边界的划分，咱们这里采纳大家比拟容易了解的业务职能的形式进行微服务划分，再次贴上咱们电商我的项目的思维导图：
从以上思维导图能够看出整个电商零碎性能还是比拟多的，咱们依据业务职能做如下微服务的划分：
- 商品服务(product) – 商品的增加、信息查问、库存治理等性能
- 购物车服务(cart) – 购物车的增删改查
- 订单服务(order) – 生成订单，订单治理
- 领取服务(pay) – 通过调用第三方领取实现领取性能
- 账号服务(user) – 用户信息、等级、封禁、地址治理
- 举荐服务(recommend) – 首页商品举荐
- 评论服务(reply) – 商品的评论性能、评论的回复性能
BFF 层
个别对客户端咱们都会采纳 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 目录下。
- app – BFF 服务
- cart – 购物车服务
- order – 订单服务
- pay – 领取服务
- product – 商品服务
- recommend – 举荐服务
- reply – 评论服务
- user – 账号服务
在每个服务目录下咱们又会分为多个服务，次要会有如下几类服务：
- api – 对外的 BFF 服务，承受来自客户端的申请，裸露 HTTP 接口
- rpc – 对内的微服务，仅承受来自外部其余微服务或者 BFF 的申请，裸露 gRPC 接口
- rmq – 负责进行流式工作解决，上游个别依赖音讯队列，比方 kafka 等
- admin – 也是对内的服务，区别于 rpc，更多的是面向经营侧的且数据权限较高，通过隔离可带来更好的代码级别的平安，间接提供 HTTP 接口
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/inde…
https://blog.bitsrc.io/bff-pa…
我的项目地址
https://github.com/zeromicro/go-zero
欢送应用 go-zero 并 star 反对咱们！
微信交换群
关注『微服务实际 』公众号并点击 交换群 获取社区群二维码。