方案一：
使用使用gorouter+haproxy作为流量入口，confd作为配置更新
Gorouter
项目地址：https://github.com/cloudfoundry/gorouter/
Gorouter来源于CloudFoundry。是一个高性能、轻量级的路由器及负载，它是整个平台的流量入口，负责分发所有的http请求到对应的instance。它在内存中维护了一张路由表，记录了域名与实例的对应关系，所谓的实例自动迁移，靠得就是这张路由表，某实例宕掉了，就从路由表中剔除，新实例创建了，就加入路由表。
Gnatsd
Gnatsd来源cloudfoundry，是一个开源轻量高性能的消息系统，gorouter依赖它来作为消息系统，进行PUB/SUB操作。
官方地址：http://nats.io/
项目地址：https://github.com/apcera/gnatsd
Confd
Confd是一个轻量级的配置管理工具。通过查询Etcd，结合配置模板引擎，保持本地配置最新，同时具备定期探测机制，配置变更自动reload。其后端支持的数据类型有：etcd、consul、vault、environment variables、redis、zookeeper、dynamodb、stackengine、rancher。不过一般使用Confd和etcd的配合使用比较多。
项目地址：https://github.com/kelseyhightower/confd
HAProxy
HAProxy是一个免费的负载均衡软件，可以运行于大部分主流的Linux操作系统上。HAProxy提供了L4(TCP)和L7(HTTP)两种负载均衡能力，具备丰富的功能。HAProxy的社区非常活跃，版本更新快速，最关键的是，HAProxy具备媲美商用负载均衡器的性能和稳定性。
项目地址：https://github.com/haproxy/haproxy
etcd
etcd是Go编写，是一个分布式一致性键值存储系统，用于共享配置和服务发现，专注于：· 简单:良好定义的，面向用户的API (gRPC)。· 安全：带有可选客户端证书认证的自动TLS。· 快速:测试验证，每秒10000写入。· 可靠:使用Raft适当分布。项目地址：https://github.com/etcd-io/etcd
今天简单分享下公司大规模容器应用中的数据流架构。
我们公司项目都是采用微服务架构设计，现服务对外访问支持两种模式如下：
-
使用的NodePort方式暴露应用端口至宿主机，上层通过配置nginx代理到这台机器的端口，然后外网SLB在代理这个nginx。这种模式下带来了一个麻烦，就是每次新上个应用都得去配置Nginx。:)
流量走向: SLB->Nginx>node(kube-proxy)>pod
-
域名分发模式，使用gorouter+haproxy作为流量的入口，域名通过泛解析到SLB上，SLB解析到内部的haproxy，haproxy代理gorouter，gorouter内部维护了一张应用的路由表，会进行匹配。这样我们在平台上一个应用创建好后，啥也不用做，就可以访问。
架构示意
选择两个Node节点作为流量节点，上面跑了confd，haproxy，gorouter容器，gorouter需要依赖nats（我们是部署在了另一个命名空间下）控制器使用的DaemonSet，开放了80,443端口。
其中原理就是
-
创建应用后如果使用域名分发模式，就会通过nats客户端注册一条消息到gorouter中，内容包含使用的域名+加上这应用的service IP
-
confd监听etcd中的key变化，如果有更新就同步修改haproxy配置规则并重新加载。
-
SLB绑定到这流量节点上的80端口（haproxy开的端口）
-
泛域名解析到SLB，用户通过域名
test.a.com请求，会经过gorouter路由匹配，匹配成功进行代理，反之访问会提示未注册路由错误。
方案二：采用API Gateway + Sidecar Proxy作为服务网格的流量入口
在目前难以找到一个同时具备API Gateway和Isito Ingress能力的网关的情况下，一个可行的方案是使用API Gateway和Sidecar Proxy一起为服务网格提供外部流量入口。
由于API Gateway已经具备七层网关的功能，Mesh Ingress中的Sidecar只需要提供VirtualService资源的路由能力，并不需要提供Gateway资源的网关能力，因此采用Sidecar Proxy即可。网络入口处的Sidecar Proxy和网格内部应用Pod中Sidecar Proxy的唯一一点区别是：该Sidecar只接管API Gateway向Mesh内部的流量，并不接管外部流向API Gateway的流量；而应用Pod中的Sidecar需要接管进入应用的所有流量。
采用API Gateway + Sidecar Proxy为服务网格提供流量入口
备注：在实际部署时，API Gateway前端需要采用NodePort和LoadBalancer提供外部流量入口。为了突出主题，对上图进行了简化，没有画出NodePort和LoadBalancer。
采用API Gateway和Sidecar Proxy一起作为服务网格的流量入口，既能够通过对网关进行定制开发满足产品对API网关的各种需求，又可以在网络入口处利用服务网格提供的灵活的路由能力和分布式跟踪，策略等管控功能，是服务网格产品入口网关的一个理想方案。
性能方面的考虑：从上图可以看到，采用该方案后，外部请求的处理流程在入口处增加了Sidecar Proxy这一跳，因此该方式会带来少量的性能损失，但该损失是完全可以接受的。
对于请求时延而言，在服务网格中，一个外部请求本来就要经过较多的代理和应用进程的处理，在Ingress处增加一个代理对整体的时延影响基本忽略不计，而且对于绝大多数应用来说，网络转发所占的时间比例本来就很小，99%的耗时都在业务逻辑。如果系统对于增加的该时延非常敏感，则我建议重新考虑是否应该采用微服务架构和服务网格，毕竟任何架构模式都不是万能的，不能因为有了锤子，看什么都像钉子。
对于吞吐量而言，如果入口处的网络吞吐量存在瓶颈，则可以通过对API Gateway + Sidecar Proxy组成的Ingress整体进行水平扩展，来对入口流量进行负荷分担，以提高网格入口的网络吞吐量。
具体的请参考：如何为服务网格选择入口网关？