随着服务网格架构的演进和成熟，我们逐步将服务路由标准化，路由功能层次化，通过插件模式让业务进行扩展，让**多活体系下沉到 Sidecar，和业务逻辑解偶，探索**多活通用、无侵入、低成本的解决方案。今年，这套体系在海外业务得到了充分验证，为未来商业化积累了实践经验。
Engineering - 站点可靠性工程），是通过软件和自动化手段，来解决系统的运维复杂性和稳定性问题。此外，安全与成本优化也成为云上运维关注重点。
K8s的成功离不开3个重要的架构选择
• 声明式（Declarative）的API：在Kubernetes之上，开发者只需定义抽象资源的目标状态，而由控制器来具体实现如何达成。比如Deployment, StatefulSet, Job等不同类型工作负载资源的抽象。让开发者可以关注于应用自身，而非系统执行细节。声明式API是云原生重要的设计理念，这样的架构方式有助于将整体运维复杂性下沉，交给基础设施实现和持续优化。此外由于分布式系统的内生稳定性挑战，基于声明式的，面向终态的 “level-triggered” 实现比基于命令式API，事件驱动的 “edge-triggered” 方式可以提供更加健壮的分布式系统实现。
• 屏蔽底层实现：K8s通过一系列抽象如Loadbalance Service, Ingress, CNI, CSI，帮助业务应用可以更好通过业务语义使用基础设施，无需关注底层实现差异。
• 可扩展性架构：所有K8s组件都是基于一致的、开放的API进行实现和交互。三方开发者也可通过CRD（Custom Resource Definition）/ Operator等方法提供领域相关的扩展实现，极大扩展了K8s的应用场景。
我带着这个命题进入业务平台，来做后续一系列的事。今天趁这个机会，和大家分享一下，关于这件事和这件事背后的一些想法，以及我对架构师的一些思考。
IT运维场景：IT运维场景从横向、纵向来看，观察的目标从最基础的机房、网络等开始向用户的端上发展；观察的场景也从纯粹的错误、慢请求等发展为用户的实际产品体验。
转化方式以及适用场景：
• Logs：我们对于Logs是更加宽泛的定义：记录事/物变化的载体，对于常见的访问日志、交易日志、内核日志等文本型以及包括GPS、音视频等泛型数据也包含在其中。
在这种多套方案组合的场景下，问题排查需要和多套系统打交道，若这些系统归属不同的团队，还需要和多个团队进行交互才能解决问题，整体的维护和使用代价非常巨大。因此我们希望能够使用一套系统去解决所有类型可观测性数据的采集、存储、分析的功能。
Logs：Logs的协议较少，但是设计比较多的日志采集Agent，我们平台除了自研的Logtail外，还兼容包括Logstash、Beats（FileBeat、AuditBeat）、Fluentd、Fluent bits，同时还提供syslog协议，路由器交换机等可以直接用syslog协议上报数据到服务端。
• 背景：线上发现有支付失败的错误，需要分析这些出现支付失败的错误的机器CPU指标有没有问题
• 实现
• 首先查询机器的CPU指标
• 关联机器的Region信息（需要排查是否某个Region出现问题）
第一点就是顶层设计。国家每5年有五年计划，这其实就是在国家整个层面的一个非常清晰的顶层架构设计，这里面对国民经济重大建设项目和生产力进行宏观的架构设计，它也是一种架构设计。在这里面，要做什么事要定义的非常清楚，要达到什么样的结果也要定义的非常清楚。
