以下是我们实际工作中微服务和 BFF 前端服务集群的架构图，其中省略了很多细节和敏感信息。相关 URL 都使用了我自己的域名。
这套架构服务从一开始在自己数据中心，然后也同样应用到了基于 AWS ECS。最后升级到 K8S。
一个基本完备的 基于 kubernetes 实现的POC。 https://github.com/zizifn/k8s-poc
- ECS 的服务现在基本都到了EKS。为了简化架构，把 router 迁移到 EKS
- NLB 比 ALB 性能更好。
静态域名，DDOS, 回源减少。
Cache-Control/expires ETag/If-None-Match Last-Modified/If-Modified-Since
- TCP 优化
- Route 优化
- 回源长连接，降低源的压力
- 多种路由策略
- Stickiness cookies
- etc
- SSL offload(不推荐)
CDN 已经根据 Stickiness cookies做了初略的路由。
Router 让我们有更细粒度的流量控制，从而做到 failover 和更细粒度的多活策略。
- 可以自定义路由测试策略。 更具 header 或者cookies
常见的数据多活策略有：
-
分布式数据库
比如 OceanBase 和 TiDB. 通过增加延迟，确保数据写入多个副本才算成功。这样如果一个region 挂了，可以快速切换到另一个 region。
-
读写分离。
会出现cache不一致的问题。
- 读的zone，如果需要写， 在 cache 设置一个marker。
- Then 写入主 DB。
- 如果 marker set, then 读取主库。else，读取从库。
- 如果从库同步过来，清除 marker。
- Dynamodb golbal table
TODO
https://github.com/sergiomarotco/Network-segmentation-cheat-sheet
- 所有应用均可通过 AWS Direct Connect 连接到数据中心。
- 默认情况下，防火墙会阻止所有流量，需提交工单以开启。
所有请求必须通过具有白名单规则的HTTP/Socket代理。
- VPC peering
- Transit Gateway
- Gateway
- privatelink
ALB with ingress controller for server side discovery.
- 架构的延续性
这一套架构从之前之际的data center 都没有改变。 之前LB 用的是 F5 LTM。 其次，还有 Enovy Router 的原因，之前是部署在 ECS，无法跨 EKS 和 ECS cluster。
所有 APP 直接通信都是通过 envoy router 完成。Envoy Router 做 cross cluster 的路由。
虽然这样集中路由，会照成 router 很热。或许未来可以用 service mesh 来解决。
Rate limit
Circuit Breaker
- Logging
统一的log log。 使用 Splunk Cloud 作为 log 收集和查询工具。
- Metrics
每个 ecs 和 EKS node 都会安装 Datadog agent，用于收集系统和应用的 metrics。
- Tracing
每个 ecs 和 EKS node 都会安装 Datadog agent，用于收集系统和应用的 metrics。
- logger level
- routes
- threaddump
https://kubernetes.io/zh-cn/docs/concepts/configuration/liveness-readiness-startup-probes/
- Liveness probe
- Readiness probe
- APP 会响应 sigterm 信号，然后退出。
CDN 会进行 failover。
完全由 Enovy Router + APP ALB 完成。
基于 docker 仓库以及 image tag 进行如下管理，
- 静态代码扫描
- 性能测试通过
- 上线前的 ticket
- 自动通过可控工具部署到生产环境
- 检测 image 是否具体上线条件，可控，可回查
申请 APP 都
Planit 网站，自动部署，其中需要各个部门 signoff