对微服务相关的技术体系建立全局性的视野和理解
1. Docker容器：
docker大部分人都熟悉或者至少是听过。Docker技术在很多技术资料和书籍上，往往会跟虚拟化技术做对比，它们的对比如下：
KVM等虚拟化技术是在操作系统级别上进行虚拟和隔离，每一个虚机都是独立的OS。
而docker是在同一个操作系统中，实现了轻量级的虚拟化。“轻量级的虚拟化”怎么理解呢？看起来docker容器是独立的操作系统，本质上是同一个操作系统中的进程隔离。所以它是轻量级的；从而，docker比KVM更省资源、资源利用率更高。
Docker的设计理念很伟大、作用也很伟大。但是docker的伟大性远不只是体现在“轻量的虚拟化”；docker的伟大性体现在：它实现了：同一个软件发布，在不同的平台上运行。
这个好处是不是很熟悉？这其实就是Java最初流行起来的原因。Python语言为了实现这一点，弄出了VirtualEnv，把依赖包都随着程序发布，才解决了多平台运行的问题。Docker的设计很优雅，一个应用都打包成一个image格式，image采用分层技术等等，这部分不是本文的重点，大家希望更深入了解的话，可以参考其他资料。
2. Kubernetes
docker镜像运行起来是一个一个的程序，多个程序合起来做成一个大的分布式应用怎么做呢？
答案很简单，一样的，程序之间互相调用就行。就好比传统的分布式应用，多弄几台服务器，一个服务器上装一个程序，程序之间通过socket或其他协议通信。基于docker的分布式应用也是如此，区别只是网络虚拟化了、CPU和内存资源也虚拟化了。
但是永远不要低估分布式应用的复杂性，举两个例子，想象我们搭建了一套分布式集群，运行了一套分布式应用：
这个集群中的某个机器出故障了（断电了、硬盘坏了等等），怎么去排查故障、怎么去修复？
这个集群中某一部分业务由于访问量增加，需要扩充支撑能力，怎么扩充？
针对这两个问题，我们很容易想到答案，那就是人过去检查机器、修复或者重装，负载过大了，就改应用的架构，上面套上负载均衡性，采用可扩展的架构。这些都是传统的办法，这些解决办法不好的地方也很明显，就是修复太慢，太费人力、成本高、对业务影响大，想象一个网站，等扩展架构都弄好了，用户也就都流失了。
Kubernetes是容器编排系统，它首要的目的就是为了解决上面这个例子里的两个问题：
分布式容器应用的可靠性，在服务器或容器应用出现问题的情况下，自动感知，自动将容器应用在集群内的其他机器里重新运行起来
分布式容器应用的可扩展性，通过启动相同的容器应用，自动的提升应用的负载支撑能力。
Google为了压制AWS，把自己的容器运行平台开源出来，成为了现在的Kubernetes，这段历史大家可以搜索了解一下。
3. PaaS
云计算的经典理论上讲三大层：IaaS、PaaS、SaaS，分布是Infrastructure、Platform、Software as a service。其中的Infrastructure指的是硬件资源虚拟化；Platform指的是软件平台，是应用软件运行的基础平台。
为什么经典理论要把PaaS这一层单独拿出来？
SaaS层是直接面向业务用户的，Iaas层是应用运行的底层物理资源，中间的PaaS是应用运行的标准平台，它包括基础数据库服务、基础中间件服务、基础开发框架和开发套件、应用部署、管理和运维服务。通过PaaS平台这一层，SaaS层更专注于自身的业务实现，运行平台和运行中间件由PaaS层提供。
因为前述的Kubernetes的成熟程度以及无可比拟的优势，PaaS层的基础架构基本上都是采用Kubernetes。
有时候会听到“中台”这个概念，有数据层（叫做数据中台）、技术组件层（叫做技术中台）和业务层（业务中台）。
中台的概念出自于阿里巴巴。随着企业规模的扩大，集团中形成了大的BU或部门，每个部门负责各自的业务体。这些业务体中有很多通用型的业务模块，把这些通用的业务模块拿出来，形成一个基础的业务层，这个业务层由在组织结构上相对独立的部门来负责，这个部门负责的东西就是中台。这便是中台的起源。
业务层中台这个概念泛化后，又演化出了数据中台和技术中台。现在（2021年）可能各个大型政企集团都在推进其各自的“中台战略”，猜想其背后的一个很重要的原因可能是：这是一次组织结构和权力分配变革的机遇，有机遇自然会有人去推进。