运维工程化
说明
实现自动化部署、监控和故障排除,提高系统的可靠性、稳定性和可维护性,为复杂的微服务架构提供了强大的支持 本文的工程化包括:
- CI/CD:使用GitLab、ArgoCD和Jenkins进行CI/CD,实现自动化的构建、测试和部署流程,减少人工干预,提高部署的一致性和可靠性。
- 服务治理: 服务注册与发现
- 可观测性:使用Jaeger进行链路追踪,将链路信息发送到Otel,同时使用ELK进行日志管理,可以帮助您快速定位和解决问题,保障系统的稳定性和性能。
- 容器编排:使用Kubernetes实现应用的自动横向扩展和缩减,根据负载情况动态调整资源,提高系统的灵活性和资源利用率。
- 身份验证和流量控制:使用Casdoor和Casbin进行auth,结合Istio作为网关,可以实现对请求的身份验证和授权,同时进行流量控制,保障系统的安全性和稳定性。
- 存储与消息队列:使用Harbor对应用容器进行push与pull,使用Kafka作为消息队列,可以实现应用的持久化存储和异步通信,提高系统的可靠性和扩展性。
- 负载均衡:结合Nginx、OpenELB和PureLB,可以实现对请求的负载均衡和流量控制,提高系统的性能和可用性。
微服务架构
BFF
全称: Backend for Frontend, 面向前端的后端服务
为什么需要?
- 当一个Web服务访问AP时, API会同时请求其它的微服务API, 就需要设计并行编程, 然后进行组装(join), 就需要对这些微服务进行封装, 找一些好用的BFF库或手写一个BFF层, 还需要处理一个局部微服务失败之后如何处理
作用
组装服务, 是前端与后端团队的中间人, 面向业务的团队, 主要用于适配前端业务, 例如首页,需要访问不同的微服务, 把这些数据进行一个组装, 聚合之类的操作
与面向资源的区别
使用场景
BFF是适合面向外网的业务接口设计. 而与面向资源的设计的HTTP Restful有很大不同, HTTP Restful强调单一性不一样, 更适合内网服务使用
非BFF的架构
graph TD
Web --> SLB
SLB --> 用户微服务
SLB --> 稿件微服务
SLB --> 账号微服务
SLB --> 广告微服务
缺点:
- 交付速度慢
- 演进慢, 需要每个服务都需要兼容
- 客户端到微服务直接通信,强耦合
- 需要多次请求, 客户端聚合数据, 工作量巨大, 延迟高
- 协议不利于统一, 各部门有差异, 需要端对端来兼容
- 统一逻辑无法收敛, 比如安全认证, 限流
单点BFF架构
graph TD
Web --> SLB --> BFF
subgraph BFF
app-interface
end
BFF --> 稿件微服务
BFF --> 账号微服务
BFF --> 广告微服务
单点BFF缺陷
缺点:
- 所有流量都经过一个BFF的app-interface层, 只要app-interface层一挂, 全部都挂了
- 流量高峰也会导致集群宕机