### 微服务分层
**BFF是什么？**
BFF即 Backend For Frontend（服务于前端的后端），也就是服务器设计 API 时会考虑前端的使用，并在服务端直接进行业务逻辑的处理，又称为用户体验适配器。BFF 只是一种逻辑分层，而非一种技术，虽然 BFF 是一个新名词，但它的理念由来已久。
一般将微服务整个体系大的方向划分为2层，见下图：
在最上层不属于微服务有很多的连接方式，有PC，有H5，有APP等等，在下层，包含了2个层，它们一起组成我们的微服务或SOA，微服务加单的划分为2层，最底下的基础服务层。
- **微服务基础服务层**
基础服务一般属于互联网平台基础性的支撑服务，比方说，电商网站的基础服务有订单服务，商品服务，用户服务等，这些都属于比较基础和原子性，下沉一个公司的基础设施的低层，向下承接存储，向上提供业务能力，有些公司叫（基础服务，中间层服务，公共服务），netflix成为中间层服务。我们暂且统称为基础服务。
- **微服务聚合服务层**
已经有了基础服务能提供业务能力，为什么还需要聚合服务，因为我们有不同的接入端，如app和H5，pc等等，它们看似调用大致相同的数据，但其实存在很多差异，例如PC需要展示更多信息，APP需要做信息裁剪等等。一般低层服务都是比较通用的，基础服务应该对外输出相对统一的服务，在抽象上做得比较好。但是对不同的外界app和pc的接入，我们需要作出不同的适配，这个时候需要有一个层去做出聚合裁剪的工作。例如一个商品详情在pc端展示和app端的展示，pc可能会展示更多的信息，而app则需要对信息作出一些裁剪，如果基础服务直接开放接口给到pc和app，那么基础服务也需要去做成各种设配，这个很不利于基础服务的抽象，所以我们在基础层之上加入聚合服务层，这个层可以针对pc和app做成适当的设配进行相应的裁剪。
除了裁剪，还有一个更重要的原因，假定PC端想获取“我的订单”的一个列表，那么Pc端必须知道和调用基础服务的几个模块（用户服务，订单服务，商品服务），pc端发起几次请求之后，在这个几个请求的数据进行汇总，这样不仅性能低下网络开销也比较大，还有pc端要承接数据聚合的这么一个工作，会让pc端变成更为复杂。如果在中间加多一个层为聚合服务层，即对网络开销进行减少，因为微服务内部是通过内网进行数据传输，也让pc端的业务变得比较简单。
这个层在各个公司有不同叫法，有叫 聚合服务，边界服务，设配服务 netflix叫边界服务，因为它处在公司微服务和外部的边界之上。这个的划分只是一个逻辑划分，在物理上或者在微服务上这两个层级其实在部署和调用没有差别。
**代码分层设计**
### 技术架构体系
- **接入层**
接入层负责把外部的流量接入到内部平台系统中来，涉及到更多是基础设施，由运维团队进行负责。
- **基础设施层**
基础设施层主要是由运维团队来进行维护，设计由计算，也计算资源的分配，网络，存储，监控，安全等等
- **网关层**
流量接进来之后，会先经过一个网关层，网关在微服务起到举足轻重的作用，主要起到反向路由，限流熔断，安全，鉴权等等的跨横切面的功能，这个层在微服务中起到核心的层次。
- **业务服务层**
整个业务服务按照逻辑划分为两次，分别是聚合层和基础服务层，聚合层对基础层进行聚合和裁剪，对外部提供业务能力。当然这个视每个公司不同情况而定，此层再划分两层是属于逻辑划分。
- **支撑服务层**
微服务并不是单单把业务服务启动起来就完毕，微服务在治理的过程中还需要更多的支持，所以由了支撑服务层。支持服务包含了注册发现，集中配置，容错限流，日志聚合，监控告警，后台服务，后台服务涉及到例如MQ，Job，数据访问，这些都是后台服务的内容。
- **平台服务层**
在微服务逐步完善的过程中，各个团队的都引入一个新的平台服务，例如由容器，镜像的管理，容器的服务编排等等，很多公司先后的引入容器化和容器编排来解决运维管理和发布微服务的难题，docker + keburnetes，确实是被微服务越来越接受。另外，通过CICD支撑起来的devops也是构建在平台服务层的这个能力。由于这个平台服务层的逐步完善也在慢慢解放运维人员一开始对微服务各种治理的不适。
