作者：金兆旭 上海创米数联智能科技倒退股份有限公司云服务开发及 SRE 工程师 负责公司云端基础设施构建及音讯网关等研发工作；十眠
创米数联是小米生态链首批亿元俱乐部成员，主营业务为智能家居产品的研发、设计、生产和销售，致力于成为以居家平安为外围的产品和服务提供商，提供多品类的全屋智能家居产品及服务。公司以居家平安为外围，洞察用户在寓居环境下的智能化需要，建设物理平安、环境平安、系统安全三类场景及服务体系，次要产品包含智能摄像机、智慧门、智能猫眼、智能门铃、智能插座等。公司旨在实现“看得见的全屋智能”，以智能家庭平安为切入点，提供多品类笼罩的智能家居解决方案。截至 2021 年 12 月 31 日，创米数联曾经在全世界 150 多个国家，销售了超过 5500 万台设施，领有了 1600 万设施和 500 万设施用户日活。
作为小米生态链的一员，创米采纳微服务架构撑持其千万日活的 IOT 设施。随着智能家居市场的疾速迭代，创米面临着公布和迭代的稳定性挑战，同时须要解决多方 IOT 接入面临的性能和平安挑战。本文将为您一一道来创米是如何应答这些挑战的。
云计算时代的蹒跚学步
创米云服务从 2016 年开创之初就抉择了云计算 + 微服务的技术路线，以应答面临的大量线上用户和设施带来的流量挑战。构建微服务之初，市面上可选用的解决方案并不多，咱们自主实现了一些微服务组件，如 frontend 业务网关和配置核心，并在小米生态云上部署容器服务来解决设施音讯、设施插件 API 和微信公众号等相干业务，并利用 HPA 及 CronHPA 等容器弹性伸缩策略来应答动静的海量线上流量。
自此创米数联在云计算时代踏上了摸索服务容器化的第一步。
新业务及新挑战
从 2019 年伊始，创米数联提出了研发自有 APP 和适配自有 APP 的智能家居设施的倒退策略。云服务部将研发重心转向自有 APP 云端业务，并逐渐接入自有品牌设施。为了实现寰球业务，创米云服务部将相干服务部署在阿里云的 4 个 Region 的 ACK Pro 专有版 Kubernetes 集群上。阿里云 ACK 为创米云提供了牢靠稳固的基础设施，向下封装好的数十款云产品，升高了云端运维人员的运维压力，疾速对接其余云产品的能力也对开发人员非常敌对，可能让创米云服务在极短的工夫内搭建一套线上可用的环境。
在自有业务研发开始阶段，咱们抉择了 Spring Cloud、Eureka 和 Apollo 等技术栈来搭建咱们的微服务基础架构。然而，通过一年半的摸索，咱们发现以后的混合架构存在着不稳固、上线部署危险大以及高人力保护老本等问题。
因而，从 2021 年开始，创米云服务决定扭转现有的微服务架构，逐渐拥抱云原生。咱们的指标是在满足稳定性和低保护老本等需要的根底上，实现所有组件的可观测性、全链路的流量治理以及更加便捷高效的 DevOps 流程。
云原生体系摸索
首先咱们将以后的 Spring Cloud 体系全面转向 Spring Cloud Alibaba，应用 Nacos 替换 Eureka，以解决 Eureka 服务端压力过大的问题，并满足单注册核心多环境分组的需要。因为 Apollo 在某些状况下存在容器磁盘压力大的问题，咱们逐渐将配置核心从 Apollo 替换为 Nacos。针对之前定制化的 Apollo 配置同步和本地非凡配置缓存，同样咱们也对 Nacos 客户端进行了局部定制化革新。
初版上线时，思考到注册核心和配置核心的高可用性、热降级、老本、可观测配套等因素，咱们没有抉择自建有状态的开源 Nacos 服务，而是间接应用了阿里云 MSE Nacos 专业版服务。至今，该服务始终稳固运行，没有呈现可用性问题。
全链路流量治理
针对全链路的流量治理，因为创米云服务所处的 AIoT 行业不同于传统互联网行业，咱们在南北向流量时不仅须要治理上游用户手机端 APP 及 Web 端的 HTTP 申请，还须要解决来自设施端的 MQTT、第三方 AMQP 和 HTTP 2 长连贯 Push 音讯的流量治理。这些音讯通常经由对立的上游音讯网关（音讯总线）监听，通过多级过滤器，如消息来源、音讯限流和产品或特定设施级别的白名单等，对音讯进行分类和打标签，而后对音讯 Topic 正则路由并进行 HTTP 异步或 rpc 申请。只有通过这些申请后，咱们能力对其进行流量治理。
因而，创米云服务的流量治理整体较为简单。咱们曾思考过采纳侵入式代码和自定义负载均衡器，并开发控制台来实现高度自定义的流量计划。咱们还思考过应用 Istio Service Mesh 的计划治理流量。然而，前者在以后百万级别设施音讯的状况下性能重大受限，后者因为设施音讯链路较长、打标较多，导致实现全链路灰度时配置文件实现较为简单，而且 Envoy 代理无奈残缺拦挡音讯总线申请等问题，因而咱们否定了这两种计划。之后在选型过程中，咱们采纳了 MSE 微服务治理。
咱们传统的 API 业务流量治理选用了多域名、多租户环境、节点隔离加多业务网关的计划配合 MSE 微服务治理来实现多个环境服务的测试开发及线上灰度部署。咱们应用多域名加 DNS 流量划分的形式对服务重构后的业务网关新路由进行测试，保障服务重构后的平安上线。咱们利用多个 K8s 集群、K8s namespace 以及多个 namespace 的注册配置核心的隔离构建了不同的线上环境，别离用来线上开发、线上测试、灰度以及基线环境部署。对于同一集群不同 namespace 的利用 pod 应用多集群隔离、利用节点亲和性、反亲和性以及节点污点等集群调度伎俩保障环境的安全性，防止不同环境间呈现的资源异样导致基线环境不可用的状况。基线环境和灰度环境同属不同命名空间的雷同节点池内，测试和开发环境利用 pod 部署在不同的 K8s 集群或节点池中。咱们的整体流程通常是在 feature 及 bug 修复后波及的服务在开发环境联调结束，在每次测试流程前将 feature 服务部署至测试环境，通过蓝绿测试将测试人员的流量导向测试环境，在多轮的笼罩及回归测试实现后，将服务部署至灰度环境，再将测试人员及 Beta 测试用户的流量导向灰度环境，通过肯定工夫的测验后，逐渐将线上基线流量导向灰度环境，灰度环境流量实现 100% 灰度后，替换基线环境镜像，最初逐渐将灰度流量倒流至基线环境。
在外围业务接入 MSE 微服务治理之后，创米云服务对局部多云部署及老我的项目通过 DNS 流量切分 + 全链路灰度的形式进行灰度，逐步将自有 APP 及自有设施的所有业务重构迁徙至新我的项目中并全副接入 MSE 微服务，实现了云上 API 业务的 100% 平安公布。
在设施音讯业务的流量治理的推动过程中，为了解决无奈拦挡音讯申请的问题，咱们首先将音讯总线拆分为控制器和路由器两局部。控制器监听各个通道的音讯后仅对音讯进行打标签和分类，而后通过异步 HTTP 申请经由对立的路由器转发到各个服务中。咱们将路由器服务定义为流量治理的入口，从而解决了音讯无奈治理的问题。而后，咱们应用对立的全链路灰度对打标签后的 HTTP 申请进行蓝绿和灰度的流量治理，并将其散发到指定的命名空间的指定服务中进行音讯解决。
MSE 微服务治理接入非常简单，只须要在 Helm 或组件核心装置 ack-onepilot 组件，重启服务便可主动注入服务，除此之外 MSE 提供了较为敌对的全链路灰度配置界面，较 Istio 计划更加易于配置和上手。通过这样的流程，创米云服务胜利实现了设施服务的更新、云云设施的对接以及固件 OTA 版本的迭代过程中的平安公布。
无损高低线解决公布扩缩容流量损失问题
无损下线逻辑图
在之前的服务发版部署或 pod 弹性伸缩过程中常常会有局部申请呈现超时或不可用的状况，因为创米云服务承载了大量的用户设施申请，这些流量损失轻则导致设施音讯重试，重大时会影响局部用户设施的可用性，后续咱们理解了 MSE 微服务治理提供了无损高低线及服务预热性能，决定将相干服务全副接入了 MSE 微服务治理的无损高低线，并调整对应服务的就绪查看，在后续的服务高低线过程中经察看再未呈现因为流量损失导致的申请不可用的状况，肯定水平上防止了由部署公布和服务缩容引起的线上流量损失问题。
新启动 Pod 的预热流量散布
可观测体系
为了实现可观测性，咱们晚期就将阿里云 SLS 日志服务集成到自有业务框架中。然而，咱们遇到了业务索引不标准、惟一 RequestId 索引异步失落以及 Spring Cloud Gateway 等 Reactive 框架利用日志异步写入 Location 导致 CPU 占用过低等问题。因而，咱们对以后的日志标准进行了改良，并在多个链路追踪计划中抉择了 Skywalking。咱们将 Skywalking 的 TraceId 写入 SLS 日志索引中，并通过对 ThreadLocal 的革新实现了异步线程的日志索引信息传递。咱们的服务挂载了 Skywalking Agent，并自定义了可选插件，而后接入了阿里云链路追踪服务。相比自建 ElasticSearch 集群，阿里云链路追踪服务更经济实惠且免保护，链路追踪服务能够间接将我的项目关联到指定的 SLS logstore 中，更不便进行链路问题排查。在上线的第一个月里，链路追踪服务帮忙咱们解决了多个我的项目中的接口性能问题。
创米云服务的指标信息的观测次要依赖于 ARMS ACK、ARMS ACK Pro、ARMS 云服务等多个开箱可用的 Grafana Dashboard，它们提供了相当欠缺的集群、Node、Pod 等多个维度的指标信息，除此之外咱们仍然会应用阿里云云监控或自定义一些 Grafana Dashboard 用来关注其余局部指标。创米云服务为了疾速预警，设置了云产品、SLS 日志、K8s 事件等多个维度的告警配置，对报警进行降噪调优，依据告警等级设置了电话、短信、邮件和飞书群多个通道的报警告诉，建设了相当全面的服务告警体系，以便相干人员及时发现问题，防止线上损失。
CI/CD 提效
早些时候因为多云部署的问题，咱们并没有对立的全自动 CI/CD 解决方案，为了解决云端 DevOps 构建部署和上线安全性等问题，咱们将所有的 Devops 流程开始全面转向阿里云云效。首先，咱们将云服务代码从自建的 Gitlab 齐全同步到阿里云 CodeUp 代码库中，并将之前的 Gitlab CI/CD 和 Jenkins 的 CI/CD 计划全副迁徙到阿里云云效流水线。咱们建设了单 Region、多 Region、多云我的项目的多条流水线，实现了从代码提交、手动或主动触发构建，到主动部署到指定的 K8s 集群和命名空间的全流程。每次构建和部署实现后，咱们会发送飞书告诉并调用 Newman 自动化测试脚本的 WebHook，依据自动化测试后果报告，评估每次服务版本公布是否满足平安标准。
稳定性评估与演练
对于线上环境稳定性评估，创米云服务选用了混沌工程的形式来测验服务的可用性，创米云服务依据本身业务对 Java 利用 OOM、缓存击穿、网络提早、K8s Pod 资源、K8s 零碎组件、要害云服务等多个维度对本身环境的服务进行全方位的演练排查，并测验可观测性中告警配置的灵敏度。咱们在没有造成线上损失的状况下发现并修复了局部破绽、欠缺了多 AZ 的云服务资源的建设、调整了未触发告警的配置，使本身架构更加强壮。在肯定水平上帮忙创米云服务在及时补救了在 HA 方面有余，并在后续的架构设计中提出了高可用优先的准则。
将来瞻望
将来创米云服务将业务网关逐步转型为云原生网关 +WASM 插件计划，代替沉重的 Spring Cloud Gateway 业务网关，进一步晋升网关性能、灵活性和可扩展性，并接入现有可观测体系。咱们将持续致力于翻新和技术升级，为用户提供更优质的产品体验。