从Ice到Kubernetes容器技术，微服务架构经历了什么？

本文主要讲解了从第一代微服务架构，到以springcloud为代表的第二代微服务架构，再到k8s为代表的容器技术服务架构的演进过程。

1、ICE分布式基础架构平台

服务编排：服务编排主要有icegrid采用xml的方式进行定义服务部署拓扑，通过命令行工具一键发布；

服务管理：icegrid中的服务运行在icebox容器中，由容器管理服务的整个生命周期，包括启动，停止，升级等过程；

服务注册：服务注册主要有iceRegistery完成，并且一主一从，防止单点故障。

负载均衡：采用客户端负载均衡机制，在客户端sdk中内嵌实现，无需编程，具有基于主机负载，轮询等多种方式；

运维平台：基于命令行和java gui的管理工具。可以用来发布grid，升级gird。停止和重启gird服务，以及服务内部状态查询。

在icegrid之后出现了dubbo，springcloud，motan等都是java语言体系内的微服务框架，并不支持其他语言，跟ice相比，完备性还达不到平台的级别，截至的目前为止只能称之为框架。

2、dubbo和springcloud对比

从核心功能来看，SpringCloud更胜一筹，在开发过程中只要整合SpringCloud 的子项目就可以顺利的完成各种组件的融合，特别是SpringCloud实现了服务网关zuul这是SpringCloud区别于其它框架的原因之一，zuul采用了代理设计模式，主要功能是服务路由，但是SpringCloud中的Service全是基于HTTP的，而Dubbo却需要通过实现各种插件来做定制，开发成本以及技术难度略高。

但是Dubbo支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜SpringCloud，如果对于系统的响应时间有严格要求，长链接更合适。

另外出现的motan，起步较晚，从架构设计和功能上看类似于dubbo，但知名度和市场占有率远远不及dubbo。

thrift和grpc通信效率非常高，跨语言，但是不支持分布式和注册中心等互联网框架中常见功能，而且对源代码本身有一定侵入性。

3、Kubernetes基础架构平台

• API Server：顾名思义是用来处理 API 操作的，Kubernetes 中所有的组件都会和 API Server 进行连接，组件与组件之间一般不进行独立的连接，都依赖于 API Server 进行消息的传送；
• Controller：是控制器，它用来完成对集群状态的一些管理。比如刚刚我们提到的两个例子之中，第一个自动对容器进行修复、第二个自动进行水平扩张，都是由 Kubernetes 中的 Controller 来进行完成的；
• Scheduler：是调度器，“调度器”顾名思义就是完成调度的操作，就是我们刚才介绍的第一个例子中，把一个用户提交的 Container，依据它对 CPU、对 memory 请求大小，找一台合适的节点，进行放置；
• etcd：是一个分布式的一个存储系统，API Server 中所需要的这些原信息都被放置在 etcd 中，etcd 本身是一个高可用系统，通过 etcd 保证整个 Kubernetes 的 Master 组件的高可用性。
• Node:node是真正运行业务负载的节点，每个业务都会以pod的形式运行，每个pod中可以包含一个或者多个container容器，其中pod被Deployment管理，可以根据服务负载进行扩容、升级、回滚等操作，pod运行在kubelet上。

4、ICE和Kubernetes对比

如果对比起来看icegrid和kubernetes有极大的相似之处；

• Kubernetes服务编排以yaml格式文件，ICE有grid.xml；
• Kubernetes pod中的运行时容器类似于icebox；
• Kubernetes node中的Service类似于icebox中的Service；
• Kubernetes中的API Server相当于ICE中Registry；
• Kubernetes中的命令行和界面工具类似于ICE命令行和IcegridAdmin界面。

ICE和Kubernetes的不同之处 负载均衡方面Kubernetes通过kube-proxy进行负载均衡，ICE通过客户端实现负载均衡。 Kubernetes没有实现RPC形式的通信框架，任何协议的通信框架都需要基于Kubernetes框架自行构建。

既然有了电信级别的框架ICE（前Corbar专家联合打造的优秀分布式基础架构平台），CNCF社区为何又要劳神费力研究Kubernetes呢?

服务负载能力：首先Kubernetes中Service，通过ClusterIp进行把经此的流量调度到pod上。通过iptables实现集群内组网，其底层是通过linux nat技术实现。传统情况下我们需要部署一个负载均衡服务，需要找到各种组件，配置，可能还要修改代码，但kubernetes的一个命令就可以把单体服务复制成多份，在连接方式上跟正常连接单体服务没有什么区别。

自动化能力：Kubernetes采用状态机模式进行设计，内部实现体现形式是控制器，一直在进行从初态到终态的判断。其中服务自动能力主要依靠Deployment实现，Deployment首先是一个控制器，它会控制当前副本的数量跟我们期望的数量一致，如果某台机器宕机，Kubernetes控制器会自动选择其他节点进行重建副本，保证发布过程中，实际副本数量和期望一致；当我们发布完成后功能有问题，可以回滚到之前版本以及各种灰度发布验证，可以想象下，如果线上环境存在几百个节点，依靠人肉处理，需要多大工作量。

探针是另一个体现自动化能力的表现，目前有存活探针和就绪探针支持HTTP、TCP以及自定义shell脚本。传统分布式服务中，长时间运行后，节点中可能会存在僵尸服务，通常的做法是进行侵入式设计，在每个服务中提供一个专有方法，循环调用检测是否正常。然后通过人为的方式处理服务故障，而kubernetes中的探针服务探测到服务不正常，可以根据策略配置重建pod自动重启服务，中间过程不需要人为干预。

在存储方面Kubernetes更是实现了动态分配，回收，对存储的全生命周期的管理过程。

分布式配置能力：以configmap为例，相比于各种分布式配置管理工具（在传统分布式集群中更有优势），configmap是拆箱即用，不用单独维护，不需要做任何源程序的逻辑修改，可以实现分布式配置各种功能。

5、总结

固然分布式架构相比于单体应用要复杂很多，但是随着服务本身的复杂度增加，单体应用因为模块划分不清晰经常为修改一个很小的功能而牵一发动全身，再加上IT行业人员流动性比较大，就造成了我们在修改项目架构和转型的阵痛中不断翻转。微服务大大增加了开发工作量并要求开发人员必须要掌握某种RPC技术，RPC在实际通信过程中产生的各种底层问题更是让人难以捉摸。现在以Kubernetes为代表的第一台容器基础架构出现了，旨在解决降低服务与服务之间的调用问题，让应用更有弹性、容错性、观测性的基础技术，让应用更容易部署、管理、交付的基础软件、但是前期需要投入大量学习和试错成本，当然任何技术都有两面性，存在优点的同时必然存在缺点，这就要根据实际情况做出选择了。

提前祝大家2020年：

雾霾都散去

好事都到来

逝者不可追

来者犹可期

推荐阅读：

Kubernetes排障指南

从零搭建Kubernetes下的nignx和tomcat

Kubernetes中如何使用ClusterDNS进行服务发现？

docker，做好你的垃圾收集

如何使用docker？