阿里巴巴云原生网关 Higress：基于 Envoy，支持 Nginx Ingress 迁移

作者 | 蔡芳芳

近日，阿里巴巴正式开源云原生网关Higress。Higress 是基于阿里内部两年多的 Envoy Gateway 实践沉淀、以开源 Istio + Envoy 为核心构建的下一代云原生网关，在标准上全面支持 Ingress 与 Gateway API，积极拥抱云原生下的标准 API 规范。此外，Higress Controller 支持 Nginx Ingress 平滑迁移，用户可以几乎零成本快速迁移到 Higress。

在容器化的云原生大背景下，Kubernetes 已经成为了基础设施与上层应用的标准接口，而 Kubernetes Ingress 又标准化了入口网关，同时社区也在积极推进 Gateway API 的标准定义来解决目前 Ingress 标准存在的一些不足，如路由能力偏弱、配置不够灵活等问题。

大家想到网关可能第一直觉会联想到 API 网关，这里有一个挺有意思的问题：在网关或者 Web 流量场景下什么是 API 呢？

回归到原始概念下，它代指一组具备某些特性的流量，用于描述该特征流量的规则称为路由规则，在 API 管理领域称为 API，在路由规则或者 API 之上可以附加很多策略，如熔断、限流、降级、认证与鉴权等等。在 Kubernetes 生态，Ingress 与 Gateway API 是用于定义路由规则的，因此 Ingress 与 Gateway API 事实上已经成为云原生下的标准 API 规范。

阿里巴巴从 2017-2018 年开始探索 Service Mesh，基于这些探索沉淀了大量 Istio 和 Envoy 的实践经验，不过早期这些实践并不太涉及网关场景。

2020 年，在代号为“本地生活战役”的项目背景下，阿里集团和蚂蚁集团两侧有一些业务上互相访问的诉求（比如支付宝首页需要展示跟本地生活相关的推送、商品信息，而这些信息往往存储在阿里侧），出于安全性和业务快速迭代的考虑，双方技术团队希望打造一个新的互通网关，通过走内部 RPC 调用的方式实现互通，替代掉原来走公网的方式。同时，大家希望借这个机会把两边的 RPC 协议定义成一个统一规范。以此为契机，阿里开始了基于 Envoy 打造下一代云原生网关的探索。

本文出自 InfoQ 特别策划的专题《Envoy 当道？云原生时代的下一代网关选型和实践》。 我们专访了阿里云研发工程师耿蕾蕾（如葑），深入挖掘阿里巴巴针对云原生网关的技术选型思考和实践路径，希望能为想要进一步了解 Envoy 和打造下一代网关的技术团队提供参考。

为什么基于 Envoy？

阿里内部一直使用基于 Nginx 演进而来的 Tengine 作为统一接入网关。因此最初做新网关技术选型时，其实有两种演进思路，一种是基于 Tengine 优化，一种是基于 Envoy 内核来扩展网关场景。当时，如葑所在团队本身就负责 Tengine 的维护工作，同时也参与探索阿里内部 Service Mesh 的落地，因此团队对 Tengine 和 Istio+Envoy 这两套技术栈都比较熟悉，技术储备上都不存在障碍。选型的关键在于，哪种技术方案可以更简单地支持前文所述的统一 RPC 协议（这个由两方团队合作定义出的统一 RPC 协议，即后来 Dubbo 3.0 中支持的 Triple 协议）。

据介绍，Triple 协议是一种类 gRPC 协议，它的大部分能力复用了 gRPC，比如序列化和通讯协议等。因此在选型网关时，首先需要新网关对 gRPC 支持友好，这样后续支持 Triple 协议的研发工作难度会小很多。恰恰当时 Tengine 上游对 gPRC 的支持并不完善，而 Envoy 诞生在 Tengine 之后，对 gRPC 的支持相对完善很多。如果选择 Tengine 的技术路线，团队前期需要投入很大的人力把 Tengine 上游支持 gRPC 的能力补齐，如果选择 Envoy 则不需要在这方面投入额外人力了。当时基于这一点考虑，团队几乎就要把 Tengine 这个思路 Pass 掉了。

此外，Tengine（和 Nginx）还存在 Reload 访问有损的问题。由于不支持配置热更新机制，Tengine 在做配置变更的时候需要 Reload，而 Reload 对于长连接会引起抖动，导致流量短暂中断，但恰恰在 RPC 请求场景下大部分连接都是长连接。这意味着，如果要让互通网关做到接入服务快速生效，就要频繁做配置变更，Tengine 就要频繁地 Reload，长连接会频繁抖动，导致流量严重抖动。如果要控制 Reload 影响则只能减少 Reload 次数，但这又会导致接入服务生效变慢。相比之下，Envoy 原生通过 xDS 支持配置热更新，就不存在这个问题。这也是团队在做技术选型时重点考量的一点。

当然，也有团队成员对选型 Envoy 心存疑虑。毕竟 Tengine 脱胎于 Nginx，而 Nginx 作为老牌网关已经在行业内应用多年，不管是业界口碑还是性能表现都很受推崇，相比之下 Envoy 只能算是初入江湖的“萌新”选手。被挑战最多的一点是，Envoy 的性能是不是能够达到 Nginx 同等水平？或者说，至少不能出现量级的差异。针对这一点，团队找了一些网关场景，针对 gRPC 协议专门做了压测。压测结果表明，未作任何优化的情况下，Envoy 的性能确实不能完全跟 Nginx 或 Tengine 持平，但还在同一个量级上，并没有出现跨量级的性能损失，而这种同一量级的性能差异是可以通过一定的性能优化工作补齐的。

并且，在打造互通网关的项目中，原本就必须做一些整体的性能优化工作。

还有另外一个因素坚定了团队选择 Envoy。当时阿里内部已经在重点推进 Service Mesh 落地，而 Service Mesh 架构本身就包括东西向使用 Sidecar 做服务治理，同时还有一个基于 Istio+Envoy 的 Gateway 负责做跨集群之间的流量互通。如果选择 Envoy 作为网关，后续就有可能跟 Service Mesh 整合成一个大的流量调度方案，在阿里内部实现以一套技术架构同时调度南北向外部流量和东西向内部流量。从长远来看，这是更有利于未来向统一应用架构技术栈演进的选择。

阿里巴巴 Envoy Gateway 演进的三个阶段

由于业务体量庞大，阿里对 Envoy Gateway 的探索主要通过对单点业务场景改造的方式来推进。阿里和蚂蚁的互通网关是第一个落地场景，如葑将其称为Envoy Gateway 1.0阶段。

这一阶段 Envoy Gateway 要应用于东西向流量的 RPC 互通，其架构部署如下图：

上图主要展示的是集团侧的架构，最终采用了 Istio+Envoy 的方案，在部署的时候又分成了出口集群和入口集群。之所以拆成两个集群，一方面是当时两边互访，蚂蚁调集团的流量要远远大于集团调蚂蚁的流量，上下行特别不均等；另一方面是分开之后两个集群可以各自维护，稳定性会更好。

Envoy Gateway 1.0 从开始立项到完成第一期研发，网关改造的核心工作差不多两个人投入了一个半月左右，其中还涉及到大量网络、安全等协调部门的工作。1.0 架构并没有完全按照社区方案来设计，社区版本中配置变更和服务发现使用的是 K8s，在阿里内部庞大的服务规模及配置量下社区原生方案不管在稳定性及性能上都无法满足要求，因此阿里这套方案重点对服务发现、配置存储组件做了替换，及优化 xDS 推送性能。

这一阶段，团队基于 Envoy 演进了网关的服务管理能力，支撑了当年双十一本地生活战役数十万 TPS 的流量洪峰。基于 Envoy Gateway 的互通网关给业务带来了实打实的收益。一方面，基于 RPC 调用方式，互访请求的延时远远好于原来走公网的方式，并且对此专门做过压测，整体延时降低了 50%-60%，同时在网关侧的延时消耗几乎可以忽略不计，对用户体验的提升非常明显。另一方面，业务上线迭代速度也加快了，原来蚂蚁和阿里要调用对方一个业务，首先要走完一套安全合规的审批流程，然后配置变更走以前的统一接入网关 Tengine，至少以天为单位，改造后走新的互通网关，业务上线时间可以缩短到小时级别，具体耗时主要取决于审批流程的快慢，网关侧支持热更新，一旦发出配置变更几乎是秒级生效。

随着阿里巴巴上云战役的推进，越来越多的场景找到如葑的团队。比如云上云下业务互通，由于 Tengine 服务管理弱导致阿里内部大量二层微服务网关需要收敛，这就需要从业务上做 Tengine+Envoy 两层网关的演进，承担南北向网关流量。在 2020 年 12 月份，团队开始了向 Envoy Gateway 2.0 架构的演进，以优酷场景为例的演进过程如下图：

Envoy Gateway 2.0 南北向的架构图如下：

在两层架构中，Envoy 网关更多承担了微服务网关和微服务治理的需求，和 Tengine 流量网关完成了整合。在这个过程里，团队支撑优酷内部多个二层微服务网关统一的工作，大幅提升了性能和运维效率。

在这一阶段，Envoy Gateway 实现了东西向、南北向全域流量的调度分发，东西向上不仅支持跨业务域的蚂蚁 RPC 互通，也扩展到了混合云的云上云下 RPC 互通场景，覆盖钉钉文档、阿里视频云、达摩院的店小蜜、智慧数字人等。2.0 阶段的业务大图如下（云上云下互通场景，以钉钉为例说明）：

随着 Envoy Gateway 覆盖的业务场景越来多，在跟优酷持续合作的过程中，双方团队不约而同提出了一个设想：Tengine Gateway（承担流量网关角色） + Envoy Gateway（承担微服务网关角色）的两层网关是否可以合并为一层 Envoy Gateway？

如葑和团队对这一想法做了调研，答案是肯定的，并且当时大家也合作设计了新的架构方案，如下图：

虽然由于各种各样的原因，这个方案最终没有跟优酷继续往下推进。但这个演进方向让如葑和团队明确了网关新的发展趋势：在以 K8s 主导的容器化背景下，由于 K8s 集群内外网络的天然隔离性，用户需要一款兼顾高性能与安全性，以及强大服务治理能力的入口网关。这也为后续团队将技术沉淀变成云产品、推进 Higress 的诞生打下了基础。

2021 年，阿里巴巴开启了中间件三位一体战役，目标是用云产品支撑集团业务。如葑和团队开始将孵化成熟的技术沉淀为云产品，即目前阿里云上提供的 MSE 云原生网关，一方面面向广大的公有云用户提供托管的网关服务，另一方面也对内服务集团。

目前 MSE 云原生网关已经支持通过 Envoy 将流量网关 + 微服务网关合二为一的技术方案。同时，通过硬件加速、内核优化等手段，团队也在持续不断地优化网关性能和网关资源部署成本。在功能扩展性上，团队做了高可用流量防护组件 Sentinel 商业化版本的集成，并支持将 K8s 的 Ingress 资源自动转换成 Enovy 网关能够识别的配置，便于大家从 Nginx 迁移到 Envoy 网关。

如今，这套经过内部实践沉淀下来的云原生网关方案 Higress 正式对外开源，以 Kubernetes Ingress 网关为契机带来了流量网关与微服务网关融合的可能性，结合阿里内部实践沉淀 Higress 实现了流量网关 + 微服务网关 + 安全网关三合一的高集成能力，同时深度集成了 Dubbo、Nacos、Sentinel 等，能够帮助用户极大的降低网关的部署及运维成本，而且能力不打折。

软件的扩展性是个持久的话题，Kubernetes 的成功离不开其强大 Controller 扩展能力的支持。据如葑介绍，Higress 提供多种形式的扩展机制，包括 Wasm 插件、Lua 插件、进程外插件，通过丰富的插件扩展机制，用户就可以使用多语言编写扩展插件。这能有效降低插件编写门槛，满足用户自定义的扩展诉求。

下一代网关尚未形成事实标准，但 Envoy 是可能性之一

如何定义下一代云原生网关，大家可能看法各异。经过这几年在网关方向上的实践，如葑及团队也有一些思考。

在他看来，下一代云原生网关首先一定要对 Kubernetes 友好，在云原生的大背景下，必须能原生地支持相应特性，而不是依靠插件化的方式来支持，这是至关重要的一点。

其次，要具备丰富的可观测性，不管是初始化状态还是持续运行状态都要能提供丰富的指标数据，用于观测和后续的自动化运维/AI 智能运维。网关作为总的流量入口，对安全性、稳定性和性能要求都很高，目前有一些可观测解决方案通过添加 Sidecar 或者注入代码来提取可观测数据，这种方法对网关来说并不可行，更多还是要依靠网关自身来提供可观测能力。

再次，过去传统网关常常是流量网关+业务网关（或微服务网关）两层架构，不仅运维成本高，资源部署成本也比较高。在云原生时代，K8s 已经成为事实上的运维底座，由于 K8s 集群网络天然是隔离的，就诞生了 Ingress 网关，来解决流量入口的问题，而这个 Ingress 网关完全可以将过去的两层网关架构合二为一，成为一个功能更强大的网关。

生于云原生时代的“后浪”Envoy 天然能满足以上三点需求。

如葑表示，虽然国内目前使用 Envoy 作为网关的开源项目或商业化产品不多，但是国外使用 Envoy 作为网关的产品或案例并不少，比如Tetrate、Gloo Edge、Ambassador（网关改名为 Emissary-ingress）等，虽然有的使用 Istio 作为控制面，有的选择自建控制面板，但大家都不约而同地把 Envoy 作为未来演进路线的一种选择。知名企业如 Twitter、Lyft 等也都在使用 Envoy 作为网关或者把网关往 Envoy 上面迁移。

这首先得益于 Envoy 原生支持配置热更新，在如葑看来，这是一个非常重要的特性。现在已经有很多主流应用选择采用长连接，现在的 HTTP 1.1 一般默认会使用 Keep-Alive 去保持长连接，后续 HTTP 2 以及 HTTP 3 也是如此，随着网络协议的发展，未来使用长连接会变得更加普遍。而配置热更新天然对长连接非常友好。

其次也得益于 Envoy 的 xDS 能力，xDS 作为一个通用的配置请求协议规范，基于它可以做灵活地扩展，对数据面+控制面的架构天然友好。

反观 Nginx，它更多推崇的是使用本地的指令配置来做配置变更，虽然作为代理程序来说很便捷高效，但用作网关则不尽然。另外，Nginx 原生不支持配置热更新，常见的做法是使用 Lua 脚本来支持，但这会带来非常大的性能衰减，如果配置热更新、可观测性等全部使用 Lua 实现，整体性能损失相比原生 Nginx 最高可能达到 70-80%，社区中针对这一问题还有一个专门的 Issue：Poor performance in benchmark。

当然，下一代云原生网关这个方向目前还没有形成一个事实上的标准，除了 Envoy，业内还有很多企业在探索这个方向，大家其实都想要抢占先机。

国外如traefik、Kong，甚至包括 Nginx 背后的厂商 F5，都在做相关尝试。如葑认为，每种产品可能会有不同的用户群体。

比如traefik，因为它原生是用 Golang 开发的，包括扩展机制也支持用 Golang 编写，所以对于使用 Golang 的群体来说可能相对更友好，同理还有国内百度开源的 BFE。有些客户确实会因为 Golang 的入门门槛比 Nginx 的 C、或 Envoy 的 C++低很多，而选择尝试基于 Golang 的网关方案。如葑认为这类方案可能比较适合的场景是，规模不是特别大，且对性能的要求没有那么高，同时又希望有一个能够快速上手的开源网关产品或者商业化产品。但一些对性能或延时要求比较高的场景，比如电商或游戏场景，可能还是选择基于 C 或者 C++的网关产品更好。因为基于 Golang 的网关方案，包括现在很流行的 Java 体系的 Spring Cloud Gateway，都避免不了 GC 抖动的问题。

国内如 APISIX 也正在云原生网关方向做一些探索。APISIX 基于 OpenResty 开发，主要采用的还是 Nginx+Lua 的方案，但对这套方案做了很多改造，使其能够更好地贴合目前云原生化的需求。如葑认为 APISIX 选择的切入点也很好，并且目前在国内确实算是做得比较成功的一个开源项目。

如葑表示，大家其实选择了不同的路线，现在很难明确地说哪一条路线一定会胜出。当然他自己还是更看好 Envoy，除了前文所述技术选型的考虑，和团队过去几年维护 Tengine 和 Envoy 的经验总结，还有一部分是出于对技术生态和技术影响力的考量。在他看来，目前 Nginx 生态已经成熟到有点固化，不管是社区活跃度还是增长其实都到了一定的瓶颈，这时候投入很多人力优化和扩展现有项目，对团队来说并不是一个特别好的选择，不如选择一个新方向。

另一方面团队更加看重的是 Envoy Gateway 与 Service Mesh 统一技术架构带来的长远价值。原来对中间件团队来说，有一个很大的痛点是，中间件架构演进无法独立于应用演进，而一定要依赖业务帮忙做升级。Service Mesh 架构提供了一个新的可能，可以把中间件所有的通用能力下沉到 Sidecar，更方便地为业务提供增量特性，缩短新业务上线的时间。这对团队来说有更大的意义。

Envoy Gateway：现有格局的冲击者？

今年 5 月份，新项目Envoy Gateway正式开源，在业内引发了一波讨论。

在如葑看来，Envoy Gateway 的开源，相当于从社区官方角度明确认可了使用 Envoy 作为网关这件事。以前大家可能更熟悉 Envoy 用作 Sidecar 的场景，一提到 Envoy，第一个想到的就是 Service Mesh 里的 Sidecar。Envoy Gateway 这个项目发起之后，大家可能慢慢会改变认知并逐步接受，Envoy 也可以用作网关并且是网关场景一个比较好的选择。

如葑补充道，新开源的 Envoy Gateway 也可能对现有的格局造成一些冲击。他认为，其实在 Istio+Envoy 这个组合里，话语权更大的是 Envoy。现在国内外使用 Envoy 作为网关主要有两个分支，一个是使用 Istio+Envoy 这套基础架构，另一个是使用自建的控制面+Envoy 组成一套架构。刚开源的 Envoy Gateway 背后两家创始企业都选择的是自建控制面+Envoy 这种方式，并没有使用 Istio。目前社区围绕新建一个能够完全贴合网关的控制面这个话题也在做一些讨论。随之而来还有更多问题引发社区讨论，比如：为什么 Envoy Gateway 不首选目前已经成型的 Istio，而是要再新建一个控制面？新的控制面以后跟 Istio 之间的关系会是什么样的？后续是否会支持 Istio 一键迁移？接下来 Envoy Gateway 社区走向值得我们长期关注。

回到 Envoy 本身，也有一些需要改进的地方。众所周知，Envoy 并不是一个容易上手使用的软件，它的复杂性劝退了很多开发者。虽然如葑所在团队因为有了前期的技术沉淀，复杂性并没有给他们造成明显困扰，但他也坦言，对于从未接触过 Envoy 或者对 C/C++不熟悉的开发者来说，Envoy 确实上手门槛比较高。

对于想要尝试 Envoy 的技术团队，团队中最好能有一定的 Envoy 技术储备，如果团队中完全没有熟悉 Envoy 或 C++的人，想要很简单地把 Envoy 用起来，或者平稳地把 Envoy 放到生产环境上使用，会面临比较大的挑战。在易用性和上手门槛方面，Envoy 确实做得没有 Nginx 好。

好的一面是，Envoy 的技术架构，包括多线程模型等，都设计得比较优雅和规范。如葑建议，开发者在上手之前可以先到 Envoy 官方博客上看一看它的技术架构和设计思想，了解完这些之后再去读代码，可能会觉得容易一些。另外，得益于 Envoy 的 Filter 扩展机制，开发者其实不需要对 Envoy 里面所有的细节都了解得非常清楚，如果想快速上手，重点了解一下它的 Filter 扩展机制大概是什么样子，然后参照社区里的 Example，就可以快速写出一个 Demo 的 Filter 并运行起来，这跟基于 Tengine 开发一个 module 的难易度是差不多的。

当然，如葑还是希望 Envoy 社区能够做一些尝试，适当地降低入门门槛，从而更好地把 Envoy 推广出去，让更多人能够把 Envoy 应用到业务中。此外，随着 Envoy 社区活跃度越来越高，参与的人越来越多，如葑觉得 Envoy 整体架构的复杂度其实是在不断膨胀的，后续社区也需要考虑如何在控制架构复杂度和新增功能两个方向上取得一定平衡。

采访嘉宾介绍：

耿蕾蕾（如葑），阿里云研发工程师，从 2020 年 5 月负责 Envoy Gateway 的构建到推出 3.0，作为技术负责人主导了整个演进过程，在云原生网关领域有着丰富的实践。

声控“万物”，天猫精灵接入Home Assistant，打造语音智能家居

本文作者：囧小平

写在前面

首先感谢来自瀚思彼岸的诸位热心网友以及Home Assistant的诸位开发者。是他们的辛勤贡献，让我们普通人也有了自己动手打造智能家居的机会。是他们的热心付出，给我们的生活带来了更多的便利。

另外，本文的阅读和操作都有一定的门槛和难度，实际动手前，建议三思而行。本教程不可能面面俱到，每一个步骤都有许多种解决方案，并可以展开为一个很大的话题。但是篇幅所限，我只能选择性地展开阐述。在本教程的引导下进行实际操作的过程中，也不可避免地会遇到种种问题。建议善于使用搜索引擎自行解决，并在适当的时候选择放弃。。。

Home Assistant相信大家都比较了解。论坛里和Home Assistant相关的原创文章也是多如牛毛。Home Assistant是一款基于Python的智能家居开源系统，支持众多品牌的智能家居设备，可以轻松实现设备的语音控制、自动化等。天猫精灵自然也不用过多介绍。天猫精灵方糖发布时，以较低的价格吸引了大批用户，估计很多值友家中都有一台天猫精灵方糖吧。天猫精灵本身也能够支持许多品牌的智能电器，实现语音控制。

但是其主流常用品牌的支持数量肯定不如Home Assistant。比如在国内智能家居领域处于领先地位的小米，自然不会把自己的蛋糕拱手让给阿里，小米自家的小爱同学第一个不答应。然而，经过Hacker们的不断努力，开源的Home Assistant目前已经能够支持控制大部分小米系的智能家电产品了。如果能够将天猫精灵的语音识别能力和Home Assistant的家电控制能力结合，让天猫精灵能够控制小米系甚至更多其他品牌的智能家电，岂不美滋滋。

有需求，就必有人折腾。不甘受制于人的程序员们帮我们解决了大部分问题，让曾经的不可能变成了可能。下面，我就讲述一下具体如何实现这个目的。

准备工作

这部分内容是比较基础的部分，基本凡是曾经利用Home Assistant构建过智能家居的，都会接触过本章节涉及的内容。这部分内容会为后续实现天猫精灵接入Home Assistant打下基础。由于是属于比较基础的部分，网络上对此的相关讨论和教程都比较丰富。所以每个步骤可能不会做太全面和深入的展开。

Home Assistant搭建

Home Assistant搭建是基础中的的基础，搭建的方式也是花样万千，相关的教程更是多不胜数。但是无论是谁写的教程，都肯定不如官方教程。所以有英文基础的都建议去读官方教程：点我直达

我这里大概阐述一下Home Assistant常见的安装载体和安装方式。

1.安装载体

Home Assistant要运行于某种载体之上，所谓载体就是一台具有Python环境的主机。它可以是一台低功耗服务器，也可以是一台闲置笔记本；可以是一台群晖之类的NAS，也可以是一块树莓派等Arm开发板；甚至还可以是你的闲置的，并且最好是已经root的安卓手机。只要这种载体具备了Home Assistant运行所需要的依赖就可以。为了让Home Assistant能够长期稳定低为你服务，这个载体最好是低功耗的，能够连接网络，并有着稳定的网络环境，而对性能方面的要求并不高。

2.安装方式

根据运行载体的不同，Home Assistant也有着多种不同的安装方式。

如果你的载体是一块树莓派开发板，我推荐使用直接烧写Hass.io镜像的方式，这也是官方推荐的安装载体和安装方式。

如果你的载体是一台服务器，则可以在安装完毕Python运行环境后，用几条简单的命令安装。选择用这种方式安装的时候，别忘记修改一下Python pip软件源为国内镜像地址，这样可以加快安装速度。具体的修改方式是：创建或修改配置文件（linux的文件在~/.pip/pip.conf，windows在%HOMEPATH%pippip.ini），修改内容为：

[global] index-url = http://pypi.douban.com/simple

如果你的载体是一台NAS服务器，那么简单便捷的docker安装方式肯定是你的首选。但是有时候我觉得docker这种安装方式有点不便于调试，也可能是我不会在docker下进行调试。

如果你的载体是一台Android手机，那么最好是root过的。我本人并没有实践过在Android手机上安装Home Assistant，感兴趣的可以参考这个教程:点我直达。那么，祝你好运。

当选好了合适的载体，安装并成功运行Home Assistant，在浏览器中输入载体的IP加默认端口号8123，就能通过网页来浏览和管理Home Assistant。走到这一步，就为后面的折腾打下了基础中的基础。

内网穿透

为什么需要内网穿透呢？我们目前所搭建的Home Assistant服务，访问的地址是一个内网IP。这就意味着这个服务暂时只能在局域网中访问。而如果想要实现天猫精灵接入Home Assistant的目的，必须让这个服务在外网也可以访问到。为了达到这个目的，可能又要经过一番折腾了。

如果你家中的宽带网络具有公网IP，那么恭喜你，实现内网穿透是一件很容易的事情。问题是，现在公网IP属于稀缺资源，大部分网络运营商并不会轻易给你一个公网IP，所以要实现内网穿透就要另辟蹊径了。

一般常用的方式有ngrok和frp。你可以选择自己购买云服务器或者VPS搭建这些服务为己所用。也可以选择一些商家搭建好的免费或者收费的服务。无论是ngrok还是frp，其服务的搭建和客户端的使用都略微复杂，展开的话都是一个比较大的话题。鉴于折腾的人比较多，其相关资源也很丰富，我就不再赘述了。

以上两种常见的内网穿透方法我都用过，由于种种原因，用起来并不顺手。后来我换用了一种更简单的方式---花生棒。首先声明这不是广告，并以京东订单截图证明我的清白。

另一方面，Oray随便在站内软文比较多，但是其确实有不少产品以简单的方式解决了我们的一些网络需求。比如向日葵远程控制和花生棒内网穿透，都成了我日常生活中不可缺少的软硬件产品。

花生棒实现内网穿透真的十分简单。首先，把花生棒通过网线，连接到需要进行内网穿透的那个设备所处的路由器上。然后，登录注册并绑定好花生棒硬件的Oray账号，进入花生壳的内网穿透管理页面。在映射列表里，增加一条映射。

在映射编辑界面，选择一个免费的花生壳二级域名。外网端口号在免费使用的情况下只能动态生成，无法指定。接着再填入内网主机的IP和端口号即可。

然后根据此设置会生成一个外网访问地址，以后就可以通过这个地址访问内网所搭建的Http服务。

一个花生棒的免费配额如下:端口映射2条，带宽速度，1Mbps/映射，花生壳流量1G/月(花生棒首年2G/月)。

两条映射被我分别用来穿透路由器管理页面和Home Assistant。暂时没有别的穿透需求，基本够用了。网速限制和流量限制对于我的应用场景也不会造成太大影响。花生棒虽然有种种限制和不足，但是好在方便易用，适合不喜欢折腾的，或者采用其他方案折腾失败的用户。

域名解析

到目前为止，你应该有一个外网可以访问的Home Assistant 服务了。如果你是公网IP，那么你的访问地址很可能是IP加端口号；如果是通过其他方式进行内网穿透，那么你得到的访问地址可能是一个内网穿透服务商的二级域名加端口号。无论哪种方式，都不如使用一个自己的域名来的方便和亲切。因此我们最好注册一个自己的域名。

域名服务提供商有很多，其注册方式也大同小异。价格上也基本没有太大区别。我是在万网注册的域名，万网目前已经纳入阿里云旗下，成为其子产品之一。传统的大家比较熟悉的com、net的域名价格偏高。另外一些比如xyz、site、fun、online这些易记住的域名虽然首年价格很低，但是续费价格略高。通过筛选，我建议使用top域名，名字既响亮，价格也很合理，三年只需要67元，续费价格则为78元。域名购买完毕后，就进入域名控制台，添加一条解析。

如果你是公网IP地址，那么需要添加一条A解析。如下图所示。

记录类型选择：A，主机记录填写的是你想要访问的地址，记录值就是你的公网IP。添加完毕后，就可以通过你的域名地址加原来的端口号访问Home Assistant。

如果你已经有一个可以访问Home Assistant 的二级域名，那么需要添加一条CNAME解析。如下图所示。

记录类型选择CNAME，主机记录和上面一样，你也可以有不同的选择，不同值所对应的含义可以通过点击右边的那个问号查看。记录值填写那个可以访问Home Assistant 的二级域名。设置并添加完毕后，效果同上，不再赘述。

至此，你应该有一个属于你自己的个性化的访问Home Assistant的域名了。

猫精接入史

在继续进行下去之前，我觉得有必要讲述一下天猫精灵接入Hone Assistant的过去和现状。这样我们就能了解为了让天猫精灵接入Home Assistant，Hassbian的诸位热心网友做了多少付出和贡献。

最早的时候，天猫精灵接入Home Assistant是通过在天猫精灵开放平台自定义技能实现的。这种方法的灵活性和扩展性都很好。但是这种方式需要使用者自己搭建PHP代理网关，并实现OAuth2认证。如果你有网站架设经验，那么可能这对你来说不是什么有难度的事情。但是对于虽身为程序员，但从未涉足Web开发的我来说，依然经历了从信心满满dao到黯然放弃的过程。

接着第二种接入方法出现了。由于天猫精灵官方支持了飞利浦Hue灯，因此可以通过HaBridge将设备模拟成Hue，从而实现对设备的控制。这种方法可以免去搭建PHP 代理网关和实现OAuth2认证的步骤，大大降低了实现的难度。然而这种方法本质上是把设备模拟成灯，因此无法实现对设备更为丰富的控制命令。

然后，一种更为便捷的接入方式出现了。Hassbian热心网友将第一种接入实现方式的代码贡献给论坛，并由论坛官方架设了一台服务器，以供广大网友使用。使用者只需要填入自己的外网访问地址和访问密码，就能将天猫精灵方便地接入Home Assistant。这就相当于论坛把颇有难度的几个步骤代替大家完成了，并贡献服务器出来为大家所用。我曾长期使用这种方式，将天猫精灵接入Home Assistant。如果不想继续折腾，那么这也是我推荐的方式。在我撰写本文的过程中，站内已经有值友对这种方法整理成文，感兴趣的可以参考。

家庭妇男的智能家居折腾之路—与君子动口不动手只差四步，天猫精灵控制HA设备

小编注：想获得更多专属福利吗？金币加成、尊享众测、专属勋章、达人福利任务你想要吗？如果想要，赶紧来申请认证站内生活家！猛击此链接很多值友在前几篇家庭妇男的智能家居折腾之路系列文章下留言，表达了折腾智能家居完全没有必要的观点。的确，现阶段的智能家居确实不够智能，甚至有些智障。举个例子，只要你吩咐一声，

NetYJ

|

赞2

评论17

收藏57

查看详情

然而通过利用Hassbian的服务器实现天猫精灵接入Home Assistant依然存在些许不足。首先，论坛所搭设的服务器采用的Home Assistant安全验证方式是legacy_api_password。目前，最新版的Home Assistant将逐步移除这种不安全的验证方式，转而采用Long-Lived Access Tokens的方式。虽然代码原作者已经增加了两种验证方式的支持，但是我一段时间前验证的时候，Hassbian论坛所提供的服务并没有合入这部分更新，现在不知道是否支持了。其次，利用这种方式，相当于将天猫精灵的指令请求先转发到Hassbian的服务器，再发送给天猫精灵的服务器。据我所知，Hassbian的服务器是架设在海外的。如果家里的网络跟Hassbian的服务器连接状况不好的话，就会影响天猫精灵对指令响应的实时性和稳定性。

既然问题出现了，那么就必然会出现解决问题的人。首先膜拜一下这位大神：点我前去膜拜。这位大神是Home Assistant官方OAuth2认证系统缔造者。曾经挡在许多人面前的OAuth2认证的搭建，终于能够被新版本的Home Assistant原生支持了。既然我们已经有Home Assistant帮我们做好了OAuth2认证，所以只需要自己再实现一个网关就好了。

这一段内容可能对于很多没有相关基础的人来说有些难以理解。没关系，我们继续往下走。

SSL证书申请

在上上一个章节里面，我们已经有了一个可以外网访问Home Assistant的域名，这个域名一般情况下都是HTTP协议的。但是如果想让天猫精灵能够顺利接入Home Assistant，我们需要的是一个加密的HTTPS的地址。为了实现这个目的，我们需要申请和部署SSL证书。

SSL证书的申请，很多人可能都会选择Let's Encrypt。Let's Encrypt是一个证书授权机构，我们可以利用它的获取证书的客户端Certbot，免费快速地获取Let's Encrypt证书。具体方法本文不打算展开，网上也有很多教程，可以搜索并参考。

我并没有使用Let's Encrypt的证书。由于我的域名是在阿里云万网上申请注册的，因此我就直接阿里云上申请证书了。具体的步骤如下。

1.进入阿里云的管理控制台，并在"产品与服务"中"安全（云盾）"中找到"SSL证书（应用安全）"。不得不说，阿里云产品太多了，找都不好找。

2.点击右上角的购买证书进入证书购买页面。

3.一般的商用的SSL证书价格都很昂贵。当然，我们只要免费的。证书品牌选择"Symantec"，证书类型先点一下"增强型OV SSL"，然后选择"免费型DV SSL",然后价格就变成0.00元了。点击立即购买。

4.购买完毕后回到控制台，你购买的证书就出现在证书列表里，想使用的话还需要进一步补全信息。

5.证书绑定域名就是访问Home Assistant的域名。因为我是在阿里云万网申请的域名，所以域名验证方式直接选择"自动DNS验证"。只要域名使用阿里云DNS，都可以通过这种方式验证。当前操作后，系统自动调用云解析API添加一条记录，完成域名授权验证，十分便捷。CSR生成方式选择"系统生成"即可。然后点击下一步，进入验证界面。

6.在这个界面点击验证，不出什么意外都会成功。这时，在你的域名解析设置页面会多一条TXT记录，就是上面所说的用来完成域名授权验证的。

7.证书申请提交后，等待审核完成。审核完毕，就可以在"已签发"中找到通过审核的证书。点击下载，选择其他类型将证书下载到本地，准备做进一步部署。

注意，证书是存在有效期的，用上面的方法申请到的证书有效期是1年。到期需要重新申请证书并在服务器上更换证书。

SSL证书配置

将上一步下载的证书解压，会得到一个key文件和一个per文件。使用文本编辑器打开这两个文件，并按照下面的格式合并为一个文件，并保存为your.cert

-----BEGIN RSA PRIVATE KEY-----

XXXX

-----END RSA PRIVATE KEY-----

-----BEGIN CERTIFICATE-----

XXXX

-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----

XXXX

-----END CERTIFICATE-----

把key文件和cert文件和传到你部署Home Assistant的服务器上。在Home Assistant的配置文件configuration.yaml中添加如下内容，根据你的实际情况做修改：

http:

ssl_certificate: /path/to/your/cert_file

ssl_certificate: /path/to/your/key_file

完成上述设置后，重启你的Home Assistant，你就可以通过HTTPS访问之前的域名了。

接入实战

从这一部分开始，进入了本文最重要的部分。原贴请参考这里：点我直达。希望你前面的准备工作已经做好了，并利用Home Assistant接入了一些智能家居，且配置正确、使用正常。

网关配置

完成HTTPS域名访问后，就给我们进行接下来的配置扫清了一切障碍了。首先，我们要先实现网关，从此地址下载代码到Home Assistant配置目录的custom_components子目录下。感谢原作者。

然后在configuration.yaml里面加入下面的内容：

aligenie:

expire_hours: 8760

expire_hours意思是多少个小时后需要重新进行授权。expire_hours的默认值是8760小时，即365天，和SSL证书过期时间一致。注意，即使有默认值，此项配置也不能省略，这样才能让插件正常工作。同时，为了方便后续的调试工作，请将log级别调整为info，在configuration.yaml加入：

logger:

default: info

这个自定义的插件就是我们要实现的网关。现在把它以插件的形式集成到Home Assistant中，省去了额外搭建网关服务的步骤。

额外配置

此时你可能已经配置好了你的Home Assistant，并添加了一些智能家居设备。但是，为了让天猫精灵识别这些设备，还需要进行一些额外的设置。原文请参考这里：点我直达。

我以我的松下吸顶灯为例，讲解一下如何进行额外的配置。我这个吸顶灯可以通过红外遥控器控制开关，我利用博联黑豆对它进行控制。其实天猫精灵是原生支持博联黑豆的，但是博联黑豆的支持设备列表里面没有我这台松下吸顶灯。所以只能依靠Home Assistant曲线救国了。在Home Assistant中，我的这台吸顶灯的配置如下，也就是很基础的博联设备的配置方法。

switch:

- platform: broadlink

host: 192.168.50.233

mac: '44:44:44:44:44:44'

timeout: 15

switches:

panasonic_light:

command_on: 'xxxxxxxxxxx'

command_off: 'xxxxxxxxxxx'

为了让天猫精灵能够识别这个设备，还需要填写以下三个重要字段，且每个字段都有固定的名称列表，不能随意修改：

1. hagenie_zone：此字段指代你设备所处的区域，如客厅、餐厅等，可选值参考这里：点我直达。

2. hagenie_deviceName：此字段指代你的设备名称，可选值参考这里：点我直达。

3. hagenie_deviceType：此字段指代你的设备类型，可选值参考这里：点我直达。

当跟天猫精灵进行语音交互式，hagenie_zone和hagenie_deviceName是比较重要的字段，再次强调，务必从可选值列表中选取。比如我的客厅的松下吸顶灯的额外配置为：

switch.panasonic_light:

friendly_name: 客厅灯

hagenie_deviceName: 灯

hagenie_deviceType: light

将此段配置放置到customize.yaml中。我如果想通过天猫精灵控制这个吸顶灯，就可以说：天猫精灵，打开客厅吸顶灯。如果吸顶灯只有一个，也可以省去说出"客厅"两个字。

我再以我的小米空气净化器2示范一下如何配置。首先，小米空气净化器在Home Assistant中的配置如下。

fan:

- platform: xiaomi_miio

name: Xiaomi Air Purifier 2

host: 192.168.50.233

token: 000000000000000000000000

model: zhimi.airpurifier.m1

然后为了适配天猫精灵网关的额外配置如下。

fan.xiaomi_air_purifier_2:

friendly_name: 客厅空气净化器

hagenie_deviceName: 空气净化器

hagenie_deviceType: airpurifier

最好将配置放到customize.yaml下，这样比较规范。完成了这一步后，我们离成功越来越近了。

AliGenie开发者平台配置

Home Assistant这边配置完毕后，我们还需要在AliGenie开发者平台进行进一步配置。AliGenie开发者平台就是阿里天猫精灵的开发者平台，其地址在此：点我直达。使用你登录手机端天猫精灵App的账号登录AliGenie开发者平台，并进入控制台。

点击"添加新技能"进入技能创建页面。技能信息里面的东西可以自行根据情况填写，没有什么特殊要求。填写完毕后点击下一步。

服务设置里面则是重点，首先要进行OAuth2的设置。最新版本的Home Assistant已经自带OAuth2，并且我们实现了网址的HTTPS访问，因此在OAuth2设置中填入如下内容，根据你的实际情况做修改，其中Client Secret可以随意填写：

账户授权连接

Client ID

Client Secret：itdoesnotmatter

Access Token URL

接着，在设备管理设置中填入如下内容，根据你的实际情况做修改：

开发者网关地址

正是因为开发者平台要求填写OAuth2和网关地址的时候，必须是HTTPS的网址，所以才有了申请并部署SSL，让Home Assistant支持HTTPS访问这一步骤。此页面余下的内容可以不用理会。

模拟真机测试

完成上述设置后点击下一步进入"测试验证"页面，开启真机测试。

这时你可以点击“在新窗口打开”，网页会跳出如下弹出窗口。

点击“账户配置”，如果你之前的网关搭建并运行都没有错误的话，会进入授权页面，此时需要输入你Home Assistant的用户名和密码。

完成账户授权验证后，如果一切正常，贵显示等待三秒返回设备列表。

等待三秒钟，不出意外的话，在设备列表中，除了你原来在天猫精灵中添加的智能家居设备，你应该也可以看到你在Home Assistant中配置的智能家居设备了。比如我在Home Assistant中添加的设备如下。

那么返回的设备列表应该是这样的，前提是你为这些设备进行了额外配置，请参照上面的相关章节。

同时，打开你手机端的天猫精灵App，在智能家居列表里刷新，正常情况下，Home Assistant中的设备也会出现在这里了。这时，去尝试一下语音控制你的设备吧。

至此，恭喜你，基本大功告成。当然你的过程可能并没有那么顺利。如果遇到问题，请仔细分析相关日志，认真检查每一步的配置。另外需要注意的是，完成测试验证后，不需要提交审核，保持现状即可。

祝君好运。

简化归纳

上面写了一大段又一大段文字，初次接触的朋友可能一下子难以接受，我在本小节将上面的各个步骤进行简单的归纳，以方便你的理解。

天猫精灵接入Home Assistant的基本步骤如下:

通过上面的归纳总结，希望你能对整体的过程有一个大概的认识，具体步骤还要去每个小章节中仔细查阅。

写在最后

本文介绍的是天猫精灵的Home Assistant接入方式。如果你有小度智能音箱，也有类似的接入方法，具体可以在hassbian论坛里面搜索相关教程。对于完美没有相关基础的人来说，实践这些步骤是有些困难的。而那些之前折腾过Home Assistant的朋友，估计弄起来会比较容易一些。但是，也依然免不了遇到这样或者那样的问题。如果遇到问题，我建议首先仔细参阅各种教程，检查自己的配置。然后利用系统日志帮你判断分析问题。

虽然折腾的过程有些枯燥，也会经常遇到各种困难。但是通过自己的努力，排除万难，最终实现天猫精灵控制各种家用电器那一刻，感觉还是很值得的。当然也不排除由于某些原因导致反复尝试，不断纠错仍然无法成功。当你遇到这种情况，没关系，享受折腾的过程并坦然放弃就行。每次的失败都会帮助你积累经验，等再有机会的时候，从头再来就好了。人生不就是各种折腾嘛。

最后，再次感谢那些为达成天猫精灵接入Home Assistant这个目的而勤劳付出的各位程序员。

相关问答

阿里巴巴ihome是阿里巴巴集团旗下的智能家居业务。ihome主要提供智能家居设备和解决方案,包括智能家居网关、智能插座、智能灯泡、智能门锁等产品。通过连接互...

先奉上今年的数据彩蛋:21秒破10亿,比去年再快7秒;2分05秒破百亿,比去年用时快了近一分钟;4分20秒破191亿,超越2012年全天成交额,比去年快了1分半;1小...首先...

公牛的和小米的都不错,两家的做工方面都很硬,但是也有不同的地方,我家用的是小米智能插座,美观实用,也有公牛的(是非智能的),我曾经看过一个评测视频,里...公牛...

学习编程的时候,看的是“如鹏网”的《这样学Java不枯燥》视频教程。课程体系的设置可以极大的激发对编程的兴趣,通过开发超级玛丽,飞机大战,吃金币,连连看...所...

一个很好的问题,本人正好对健康码进行了一次深入研究,现在试着回答一下你的问题。健康宝是防疫健康码的一种,是适用于北京地区的健康码,其本质上是一种二维...(...

谢谢邀请。目前.net平台某款微服务要说很红很好好像真的都谈不上,不像Java的SpringCloud这样有比较高的人气,但据说可使用SpringCloud来开发.NetCore应用(...

小爱音箱在控制智能家居方面还是非常好用的,打开台灯、电视、窗帘、扫地机...都是“一句话的事”,交互也比较自然流畅。这里谈一下语音交互在智能音箱上应用...

云计算概念已深入人心,越来越多的企业将业务迁移到云上,越来越多的人通过学习培训加入云计算行业。Gartner分析报告显示,2019年的全球公有云市场规模将超越2...

阿里巴巴的字体图标怎么用不了呀,总是提示有错误,明明和示例上写的一样呀!是我哪里写错了吗?6900浏览6回答WPSPPT怎么设置声音在几张幻灯片中一直播放10...

一般来说,最基础的就是智能灯光,智能安防,电动窗帘,背景音乐,智能门锁,智能电气控制。现在基本上都是用ZigBee无线技术的,扩展性强。1.小米的米家智能家居2.和...