今天我们将之前内容进行整合并进行扩展，仍然用大家熟悉的planespotter的微服务应用，跨企业的两个数据中心站点分布式部署，通过VMware合作伙伴F5 BIG-IP DNS实现全局负载均衡，将不同地域或者不同ISP的用户智能引流到不同的数据中心中planespotter的web前端和app服务，而在数据中心内部，采用NSX内置的与PaaS平台原生集成的4层以及7层负载均衡实现本地微服务负载均衡，从而通过F5 GTM+NSX SLB作为LTM实现企业微服务双活架构。而通过NSX实现集中式管理多中心的微服务的所有网络，安全和负载均衡策略，简化opex，让业务部门或者devops流程自动化部署微服务时全自动化交付网络服务。
我们先来介绍一下今天demo的多中心网络逻辑拓扑，如下：
在BJ-DC1中，将planespotter微服务的web前端部署在之前我们demo过的环境bare-metal Openshift cluster中，app和redis部署在开源k8s/第三方PaaS中，将mysql部署在vsphere IaaS，ADS-B部署在bare-metal物理服务器上（大家如果对这个微服务不熟悉，可以参考公众号第一篇文章）。
在BJ-DC2中，将planespotter的web前端和app中间件部署在VMware PKS容器云中。
“双活微服务应用跨越不同的CaaS，PaaS，IaaS，bare-metal实现任意环境部署，而通过NSX无处不在统一管理所有的网络，安全及负载均衡策略，在demo中，部署统一的NSX Manager，controller集群，DC部署独立的Edge DPDK集群，两个中心通过VC实现统一集中式管理计算集群。在真实环境中，用户可以选择统一或者部署独立VC，统一NSX或者独立的NSX-T在不同的DC，通过NSX global policy manager实现策略一致性部署。
而部署在多中心南北向的web前端的入口，通过F5 BIG-IP DNS也就是GTM实现智能DNS流量调度，在本次demo中，通过不同的request source将client导流至不同DC的NSX 4-7层负载均衡器。
而通过F5 BIG-IP DNS与NSX SLB可以实现完美集成，通过NSX与PaaS平台集成，实现全自动化负载均衡器配置及部署，同时将各DC local NSX SLB作为server可以添加到GTM，并将NSX SLB virtual server通过GTM与link相关联。
接下来进入demo时间，我们先看一下计算环境，如下图：通过多个vsphere集群实现K8S集群，PKS集群资源的跨中心统一调度部署，（注意，demo为了简化，并不是按照生产级设计），PKS可以支持AZ，在本demo中，部署在同一个AZ中。”
接下来看一下NSX无处不在的网络环境，通过NSX统一管理bare-metal Openshit以及bare-metal ADS物理服务器，如下图，可以看到一个两节点bare-metal Openshift集群，以及物理机Ubuntu-ADSB。
下图为NSX与vCenter集成，统一管理部署在vSphere IaaS上的K8S及PKS集群：
下图为BJ-DC1和DC2通过与各自的PaaS或者CaaS平台集成，实现全自动化的Geneve逻辑交换机，多租户路由器自动化部署，此部分在之前的公众号文章有过介绍，更为详细的部分未来跟大家分享：
接下来我们看一下，通过NSX与PaaS集成实现的全自动化SLB自动化创建及部署，以及planespotter web前端的负载均衡策略上线：
下图为PaaS集群部署以及微服务上线时，全自动化创建的负载均衡virutal server：
接下来我们看一下两个中心微服务上线的状态
下图为BJ-DC1，web前端在openshift集群的部署，以及route的配置，
下图为App及redis在K8S上的部署和配置，
下图为BJ-DC2，Web和App微服务的配置和部署状态：
接下来我们来看一下F5 GTM的智能DNS实现，创建两个DC，如下图，
创建4个BIG-IP Server，将GTM以及NSX-SLB加入到不同的DC，如下图，
为planespotter的微服务应用创建wide ip，如下图，
将NSX SLB以及virtual server加入到planespotter的wide ip中，如下图：
设置基于Topology实现planespotter微服务的多中心智能DNS负载均衡，如下图，
创建Topology record，将部署在不同地域的用户及客户端导流给不同的BJ-DC, 实现多中心负载均衡策略部署。
接下来，登录两台部署在不同region的windows客户机，通过nslookup查询微服务的域名，我们可以看到，F5 GTM将DNS A记录返回给不同的DC NSX SLB。如下图：
我们在两台不同region的win客户机访问planespotter.f5.vmware.local微服务域名，发现通过BJ-DC1和BJ-DC2的实现双活访问，如下图，10.11.28.0/24网段为DC1的Pod网段，10.88.4.0/24为DC2的Pod网段，
通过F5 GTM与NSX SLB集成，可实现在GTM按照用户需要将流量切换至不同DC的不同ISP运营商，如下图，我们将DC1的微服务前端流量均切换至DC2：
我们看到Region1的客户端的nslookup请求被GTM redirect到了DC2的NSX SLB，如下图：
我们可以看到Region-a的客户端仍然可以访问planespotter的微服务，但是访问的是BJ-DC2的web前端，与Region-b的客户端一致，如下图：
应用已经完美多活上线，更为重要的是，如何secure多中心微服务，如果统一策略的部署？通过NSX无处不在可实现整个planespotter跨中心微服务组件之间以及南北向的安全均由NSX安全微分段实现完善的保护，统一安全策略的部署，如下图：
总结，通过VMware的SDDC以及NSX实现多中心微服务计算，存储和网络全自动化部署，通过NSX无处不在实现统一安全及微服务负载均衡自动化，通过VMware合作伙伴F5 Networks实现多中心智能DNS及流量调度，为用户交付真正的微服务多中心多活解决方案。
