0. 应用开发的趋势
这几年应用开发的趋势，从传统的单体应用升级到微服务架构已是大势所趋。
抛开巨型互联网企业不谈，中大型企业微服务架构也已成了企业开发的首选，就连小公司对于微服务开发也跃跃欲试。微服务架构一统企业开发的时代已经到来。
如果，你的企业还在进行传统的单体应用开发，那么你必须意识到你已经落后了，落后是要挨打的。
1. 单体应用到微服务的挑战
一项新技术的崛起是鼓舞人心的，但是在这过程中必然会遇到很多挑战，这些挑战是来自技术层面的。
我们先来看一下单体应用和微服务的结构图比较。
单体应用:
单体应用
微服务:
微服务
从上面两幅图可以看出，传统的单体应用多个模块之间在单服务器上的单进程内进行通信，而微服务架构下则演变成各个服务多进程跨服务器之间的通信和交互，变得复杂了许多。
微服务之间的通信，同步方式往往通过类似REST形式的HTTP通信，异步的话则通过类似AMQP协议的消息队列机制。
这里我们遇到的第一个挑战来了。
微服务的扩展
服务的单独扩展
你的企业应用如果有很多微服务，它们各自的扩展是不一样的。
比如，登陆微服务的并发和访问压力比较大，可能需要进行负载均衡，而且还不止一个。
从上面的图中我们可以看出，菱形微服务进行了2台服务器3个进程的扩展，而圆形服务则不需要进行扩展。
既然我们引入了微服务，服务之间肯定有着错综复杂的调用关系吧。
那么，我们遇到的第二个挑战来了。
微服务间复杂的依赖关系
还是用图来说话。
传统的单体应用，各个模块间的调用是有着顺序的，我们往往可以用树形结构来表示，见下图:
单体应用树形依赖链
微服务并不是树形的，而是更复杂的网络结构，见下图:
微服务网状依赖链
从上面的比较可以看出，微服务的依赖关系是网状的，要复杂很多，如果管理这些依赖，追踪服务间的调用，这又是一个新的挑战。
最后，我们既然开发了那么多微服务，那么我们的服务肯定是要发布的是吧。但是问题来了，那么多的服务，我怎么一下子发布呢，而且，原来的持续集成现在应该怎么做呢？
那么，这就又是一个挑战: 微服务的发布和持续集成。
2. 容器技术的崛起
在容器技术之前，我们更多的是应用虚拟机(VM)技术，我们在一个服务器上可以开辟多个虚拟机，每一个虚拟机就相当于一个小型的服务器，虚拟机之间互相通信，虚拟机内部我们安装对应的软件和应用。
那么容器技术是什么？
容器相当于在主机内运行的一个单独隔离的进程，它单独消耗该容器内的应用所需要的资源。
相比于虚拟机来说，容器更轻量，不需要像虚拟机一样需要额外的进程， 能够运行更多数量的应用。
还是用图来说话
应用运行在虚拟机上的结构图:
虚拟机应用
应用运行在容器中的结构图:
容器中的应用
Docker容器化平台
容器技术的崛起，必须提到Docker。
不得不说，Docker已经成为了容器化技术的事实标准。
Docker是什么？
Docker is a platform for packaging, distributing, and running applications.
Docker是一个用于打包，发布，运行应用程序的平台。
Docker的关键概念
-
镜像(Images)
镜像是用来把你的应用和它的环境打包进去的东西。
镜像包含了应用所需要的文件系统和一些其它的元数据，比如镜像要运行时的路径。 -
注册仓库(Registries)
Docker的注册仓库(Registries)是用来存储和共享docker镜像的。
你可以通过推(push)和拉(pull)的方式上传和下载镜像。
仓库中的镜像可以使公有或私有的。 -
容器(Containers)
容器是一个单独的运行在主机上的进程。
它包含自己需要的资源(eg: CPU, RAM, etc)，并且资源独立。
构建，发布和运行Docker镜像的流程
构建，发布和运行Docker镜像的流程
- 声明从哪里拉取镜像
- 构建镜像
- Docker推送镜像到仓库
- 声明如何运行镜像
- Docker从仓库拉取镜像
- Docker以容器的方式运行镜像
3. Kubernetes介绍
之前说了，要维护那么多微服务的容器，而且它们之间又有着错综复杂的依赖关系，是一件非常复杂且耗时的事情。如果节点上千，变成了一个不可能完成的任务。
那么，我们需要一个好的容器编排和管理的系统。
Kubernetes是什么？
Kubernetes是当前被业界广泛认可和看好的基于Docker的大规模容器化分布式系统解决方案。
它是谷歌的Borg(谷歌的久负盛名的大规模集群管理系统)的一个开源版本。
Kubernetes是一个开放的平台。
它不局限于任何一种语言，没有限定任何编程接口。
Java, Go, C++, Python编写的服务，都可以被映射为Kubernetes的服务。
Kubernetes运作原理
Kubernetes把所有的服务节点统筹为一个数据中心，作为一个可发布的平台，见下图:
Kubernetes运作原理
从上图可以看出，开发人员通过编写App描述来将应用通过master部署到任意多的worker节点。
Kubernetes就像一个操作系统，它具备以下功能:
- 服务发现(service discovery)
- 扩展(scaling)
- 负载均衡(load-balancing)
- 自愈(self-healing)
- leader选举(leader election)
Kubernetes架构
Kubernetes架构
-
master节点
控制和管理整个Kubernetes系统 -
worker节点
运行实际部署的应用程序 -
Control Plane
控制整个集群。
它包含以下组件:
- API Server 组件通信
- Scheduler(调度器) 调度，部署应用程序的工作节点
- Controller Manager 管理集群，例如: 复制组件，跟踪工作节点，处理节点失败等。
- etcd 集群配置存储(分布式存储) -
Kubelet
负责和API Server通信，管理节点上的容器。 -
kube-proxy
它是Kubernetes的服务代理，负责负载均衡。
4. Kubernetes的优势
-
简化了应用部署
Kubernetes将所有的工作节点暴露为一个单独的部署平台，开发人员不需要知道服务器的细节。 -
提高了硬件的利用率
让你从基础架构解耦。
Kubernetes会根据你的描述需求，从现有的节点中挑选出最合适的节点来运行你的应用程序。
Kubernetes能让应用移动，找到最优的节点。 -
健康检查和自愈
Kubernetes监控应用，一旦发生节点失败，会自动把应用调度到其它节点。
这让运维团队把精力放在修复坏掉的节点上，而不是去重新分配节点。
如果你的应用有足够的闲置节点，甚至可以暂时不用理会失败，比如在凌晨。 -
自动扩容
Kubernetes监控应用，自动调整应用的实例数量。
如果Kubernetes运行在云架构上，弹性扩容会变得更加容易。
网友评论