发现身边事儿、聊点周奇遇，我是沈二，期待奇遇的互联网灵魂~、一起聊天吹水，探索新的可能~wx:breathingss，入圈吧！
主题
本期实践的是docker-compose 进行Higress的安装内容,我主要的诉求是sass化时能够解决每个sass用户拥有独立的访问域名或者地址,而非采用传统的登录提供租户ID的模式,这两者的区别主要是需要多解决一个nginx发布配置的问题,当然能够解决更多的配置型策略，那是也是极好的,以下是验证过程,初步符合预期。
背景
行业中通常把网关分为两个大类：流量网关与业务网关，流量网关主要提供全局性的、与后端业务无关的策略配置，例如阿里内部的的统一接入网关Tengine就是典型的流量网关；业务网关顾名思义主要提供独立业务域级别的、与后端业务紧耦合策略配置，随着应用架构模式从单体演进到现在的分布式微服务，业务网关也有了新的叫法 - 微服务网关（图示说明如下）。在目前容器技术与K8s主导的云原生时代，下一代网关模式依然是这样吗？
Higress定位
在虚拟化时期的微服务架构下，业务通常采用流量网关 + 微服务网关的两层架构，流量网关负责南北向流量调度和安全防护，微服务网关负责东西向流量调度和服务治理，而在容器和 K8s 主导的云原生时代，Ingress 成为 K8s 生态的网关标准，赋予了网关新的使命，使得流量网关 + 微服务网关合二为一成为可能。 作为面向南北向的公网网关，使用Waf防护异常流量是很常规的需求，而且随着互联网环境变得越来越复杂，用户对防护的诉求是持续增强的，常规做法是将流量先接入Waf安全网关，过滤后再将流量转发给流量网关，最后到达微服务网关；Higress希望通过内置Waf模块，使得用户的请求链接只经过Higress就可以同时完成Waf防护、流量分发、微服务治理，既可以提升链路RT，也可以降低网关的运维复杂度。因此Higress实现了流量网关 + 微服务网关 + 安全网关三合一的高集成能力。
引导教程
基于 Docker Compose 进行独立部署
Docker Compose 是用于定义和运行多容器 Docker 应用程序的工具。通过它，我们可以使用 YAML 文件来脱离 K8s 集群来实现 Higress 网关的独立部署。
前置需求
为了拉平不同操作系统的运行时差异，当前版本的部署方案是基于 Docker Compose 设计的。所以在使用这一方案进行部署之前，请先在本机安装好 Docker Compose，随后确认以下命令可以正常运行并输出 Docker Compose CLI 的帮助信息：
bash
docker compose安装命令
bash
curl -fsSL https://higress.io/standalone/get-higress.sh | bash -s -- [DESTINATION] [OPTIONS...]波折的路
来了第一个错误提示 
马上检查一下是不是没有安装,额，习惯性的（明明记得已经装了）,注意这个其实已经将相关的文件进行了下载
bash
docker-compose versiondocker-compose升级
先看看yum 的包地址，不出意外的话,应该是1.18的版本, 我想要安装v2版本的,
bash
yum --showduplicates list docker-compose
yum list docker-compose --showduplicates | sort -r这里是版本对应关系 
这里的需要从github上头下载,但网络速度堪忧,下面用的是镜像地址,速度有保障
bash
sudo curl -L https://hub.yzuu.cf/docker/compose/releases/download/v2.2.3/docker-compose-linux-x86_64 -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose处理完成之后,在相关路径下下载路径下/higress/ 执行,输入端口采用默认即可,如果需要调整,根据需要进行调整
bash
./bin/configure.sh -a控制台配置
因为我是在虚拟机中安装的,此处的console地址访问如下
arduino
http://192.168.145.130:8080/路由配置
这里的路由配置起到的作用和nginx差不多,但配置化和粒度支持更广泛,比如可对head、get参数请求头做进一步的规则切割,匹配到指定的内容规则才会生效 
每条规则的策略有一些通用的适应场景，即针对不同的规则可以做一些转接适配,如跨域、重写等常规,以及服务安全验证配置化等操作,同时提供Wasm插件化扩展机制,适配不同业务的扩展 
服务来源
这里支持一些nacos、Zookeeper、Eureka、固定IP等不同框架体系下的流量融合,这里官方提到的灰度和渐进式平滑改造,能体会到一部分,有些项目改造又觉得鸡肋和不值当,部署调整又觉得不统管,这个方案是个不错的选择 
服务网关
代理规则的一些header粒度更细分的规则筛选，以及策略中header转接轻量化处理能够满足具体的要求 
至于后续的跨域、用户验证有待于进一步的渐进式尝试和验证。
PS
以上就是具体的安装以及部分验证体验分享