探讨基于阿里云容器技术架构(一)

原文作者:李同刚
原文链接:https://developer.aliyun.com/article/738878?spm=a2c6h.12873581.0.0.3a2b115ex69Iht&groupCode=cloudnative

更多云原生技术资讯可关注阿里巴巴云原生技术圈

为什么有这个主题?

记得2018年参加上海KubCon大会时,演讲人现场对国内生产使用Kubernetes情况的调查,现场举手的寥寥无几。时至今日,参加2019“MVP闭门大会”和“云栖大会”,感受到“云原生”无处不在。那么当容器、容器编排遇到传统微服务架构,会擦出怎样的火花,这其中有哪些坑?人类对科学的追求总是义无反顾的,进化到云原生时代,我们的机遇和挑战是什么?
希望在这个场合一起探讨下,没有对错,只有适合与否。关键是当开始有沟通,才可能继续往前走。
这个系列文章采用总分总的方式写,第一篇主要探讨整体架构,后面文章探讨各部分更具体的技术方案,最后总结。

探讨整体架构

让我们从一张图开始第一篇正式内容,这是一个可能的最小化服务化架构:
探讨基于阿里云容器技术架构(一)

这是一个传统架构和容器技术混合的架构,在全面介绍之前,我们先分别看下各自的发展史,“知道从哪儿来,方知道我们往哪儿去”。

从传统部署时代到容器部署时代

下面这张图从运维角度描述了,应用从传统部署时代如何发展到容器部署时代。也折射出企业上云的发展过程。
探讨基于阿里云容器技术架构(一)

在国内,阿里云吹响了企业上云的号角。第一阶段,是IT基础设施云化,包括虚拟机、网络等上云,降低企业运维成本、提升弹性伸缩能力。第二阶段,是核心架构云化,包括阿里云数据库、阿里云微服务引擎 ( Microservice Engine, 简称:MSE )、全局事务服务GTS等,Kubernetes或许也算。第二阶段的升级版可能是全面拥抱Cloud Native,随着有状态应用和无状态应用全面拥抱Kubernetes,我们可以猜测走向了面向Kubernetes编程时代,开发人员不必关心微服务治理的各种技术栈和开发语言(诸如:Golang、Java等),写好业务代码,定义好云原生开放应用模型(OAM),发布上线即可,应用将变得更轻量、接入成本更低、迭代更敏捷。
IT行业发展是如此迅速,却又是如此必然。类比下,编程语言从汇编、C++、Java到新型语言Golang,无不是从复杂到易用的过程。易用、轻量贯穿整个行业的发展脉络,所以我们有理由相信这一天的到来,尽管过程比较曲折,Istio如今还不尽如人意。

那些年,我们折腾过的微服务架构

下图来源于蚂蚁金服@卓与( 一个帅又专业的小伙:) )的一次SOFAMesh分享。基本代表了,传统微服务架构Dubbo、SOFABoot、Spring Cloud等微服务架构核心能力和应用之间的关系。这类微服务架构提供“胖客户端”集成到应用,这个小胖每次升级都会影响到应用,也增加了中间件开发团队和业务团队沟通、协调成本,因为耦合太紧了。让我们寄希望于Cloud Native来解吧!
探讨基于阿里云容器技术架构(一)

混合架构

熟悉Kubernetes的同学知道,他有几个对于微服务架构来讲重要能力:
容器编排能力
架起了容器镜像和硬件资源的桥梁,通过yarml声明轻松发布“可执行”程序,配合Liveness 和 Readiness可以做到不停机滚动发布,这都减轻了微服务运营成本。
服务发现能力
Kubernetes可以使用DNS(这是一个较早的基于服务端的服务发现模式)名称暴露一个应用集群的服务地址。Kubernetes还可以用负载均衡,把流量分配到Pod,从而使服务更稳定。这部分看着是否和“胖客户端”的服务发现有点儿像。
在Service Mesh没有完全落地之前,我们是否可以结合Kubernetes上述能力和传统微服务架构能力,各自发挥所长,组成一个混合架构呢,于是有了开篇第一张大图。

本篇总结

我们探讨了容器技术和传统微服务架构特点,并且尝试结合各自优势,组成一个混合架构。
后面我们就具体的技术领域做探讨和可能的坑。

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

上一篇:Serverless Kubernetes入门:对kubernetes做减法


下一篇:容器镜像服务企业版发布,更强更安全