为什么有这个主题？
记得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上述能力和传统微服务架构能力，各自发挥所长，组成一个混合架构呢，于是有了开篇第一张大图。
本篇总结
我们探讨了容器技术和传统微服务架构特点，并且尝试结合各自优势，组成一个混合架构。
后面我们就具体的技术领域做探讨和可能的坑。
