亚马逊AWS官方博客
基于AWS Cloud Map 的混合微服务架构
背景概述:
随着最近几年,越来越多的公司使用“微服务”来构建他们的系统或应用架构。在微服务架构中服务治理是一个重要的问题,在没有服务治理的分布式集群中,各个服务之间通过手工或者配置的方式进行服务关系管理,遇到服务关系变化或者增加服务的时候,手动配置极其麻烦且容易出错,在容器化技术以及kubernetes成为主流前,行业内使用Eureka\Zookeeper\consul 方案来处理这一问题。
本文的背景中客户就是使用consul基于EC2来构建自己的微服务架构,随着kubernetes技术的成熟及容器在成本,效率上的优势,客户计划对现有架构进行容器化改造,使用EKS实现服务间的治理。基于业务稳定性,连续性的考量,客户要求构建混合的微服务架构,服务可以在现有consul架构及未来EKS中共存,后期小批量平滑的进行迁移。(从EC2迁移到容器)
在本文中,我们将向您介绍如何帮助客户解决这些方面的挑战,通过AWS Cloud Map 服务来构建混合的微服务架构。
方案概述:
如上图,在本示例中在位于同一VPC内的有Consul和EKS两个集群,我们可以通过AWS Cloud Map 实现混合基础设施间的服务发现。
流程如下:
- 构建consul集群,模拟服务注册到consul-server
- 通过consul-aws client 同步consul-server中的服务到AWS Cloud Map
- 在EKS 集群中构建测试服务,通过appmesh-controller 自动同步服务到AWS Cloud Map
另外也可以使用AWS Cloud Map MCS Controller for K8s 同步信息到Cloud Map,具体请查考https://github.com/aws/aws-cloud-map-mcs-controller-for-k8s
- 服务通过DNS 实现混合架构间的通信
环境部署:
注:本示例的整个流程选择在us-east-2区域进行,使用EC2 Iam role 获取相应权限
- Consul 环境设置
通过consul ui 确认服务已注册到consul server 中
- AWS Cloud Map 设置
创建完成后,会自动创建相对应的Route 53 Hosted zones
通过控制台获取aws cloud map Namespace ID
控制台查看Nginx 服务已同步到 aws cloud map 中,并且在 Route 53 Hosted zones 增加了一条对应的A记录
- EKS 资源设置
EKS 集群的创建请参考官方文档
注意:本方案只需要通过app mesh controller 把pod IP 自动同步到cloudmap 上,mesh功能本方案并不需要,要disabled掉envoy的注入。
通过控制台查看Virtual nodes 已成功创建
Cloud Map cloudmapdemo nignx 服务里也获取到pod 的相应信息
Route 53 Hosted zones 增加了一条对应的A记录
- 测试验证
#edit eks nodegroup sg inbound rules
允许VPC 10.10.0.0/16
的所有流量
# 多次 ping 或dig 查看返回结果的IP 变化
#使用CURL 测试,两次curl的结果也不同,一次请求到pod 上,一次请求到ec2 上
注意: cloud map nginx dns 记录的ttl 要设为0 ,减少cache 对测试的影响
总结:
在本方案中,我们在VPC内创建了consul和EKS集群,在两种不同的基础设施上创建不同的服务,并使用AWS Cloud Map的发现服务建立起通信。利用 AWS Cloud Map能够找到服依赖的所有基础设施资源的位置,而不需要关心底层的资源运行在那里,比如ECS、EKS、Fargate以及EC2实例等。本方案可以给大家一个启示,大家可以进一步扩展实现更多的混合基础设施场景。
参考:
https://aws.amazon.com/cn/blogs/china/cross-amazon-eks-cluster-app-mesh-using-aws-cloud-map/
https://www.hashicorp.com/blog/enabling-service-discovery-consul-cloud-map
https://github.com/aws/eks-charts/blob/master/stable/appmesh-controller/README.md#upgrade