本文主要讲解了从第一代微服务架构，到以springcloud为表明的第二代微服务架构，再到k8s为表明的容器技术服务架构的演进过程。java
一、ICE分布式基础架构平台
node
服务编排：服务编排主要有icegrid采用xml的方式进行定义服务部署拓扑，经过命令行工具一键发布；linux
服务管理：icegrid中的服务运行在icebox容器中，由容器管理服务的整个生命周期，包括启动，中止，升级等过程；web
服务注册：服务注册主要有iceRegistery完成，而且一主一从，防止单点故障。redis
负载均衡：采用客户端负载均衡机制，在客户端sdk中内嵌实现，无需编程，具备基于主机负载，轮询等多种方式；spring
运维平台：基于命令行和java gui的管理工具。能够用来发布grid，升级gird。中止和重启gird服务，以及服务内部状态查询。docker
在icegrid以后出现了dubbo，springcloud，motan等都是java语言体系内的微服务框架，并不支持其余语言，跟ice相比，完备性还达不到平台的级别，截至的目前为止只能称之为框架。shell
二、dubbo和springcloud对比
编程
| 核心功能 | dubbo | springcloud |
| 开发语言 | java | java |
| 跨编程语言 | 不支持 | 不支持 |
| 服务注册中心 | zookeeper、redis | springcloud eureka |
| 服务调用方式 | RPC | rest api |
| 服务网关 | 无 | springcloud zuul |
| 断路器 | 不完善 | springcloud hystrix |
| 分布式配置 | 无 | springcloud config |
| 分布式追踪系统 | 无 | springcloud sleuth |
| 消息总线 | 无 | springcloud bus |
| 数据流 | 无 | 基于redis、kafaka等 |
| 批量任务 | 无 | springcloud task |
从核心功能来看，SpringCloud更胜一筹，在开发过程当中只要整合SpringCloud 的子项目就能够顺利的完成各类组件的融合，特别是SpringCloud实现了服务网关zuul这是SpringCloud区别于其它框架的缘由之一，zuul采用了代理设计模式，主要功能是服务路由，可是SpringCloud中的Service全是基于HTTP的，而Dubbo却须要经过实现各类插件来作定制，开发成本以及技术难度略高。
设计模式
可是Dubbo支持各类通讯协议，并且消费方和服务方使用长连接方式交互，通讯速度上略胜SpringCloud，若是对于系统的响应时间有严格要求，长连接更合适。
另外出现的motan，起步较晚，从架构设计和功能上看相似于dubbo，但知名度和市场占有率远远不及dubbo。
thrift和grpc通讯效率很是高，跨语言，可是不支持分布式和注册中心等互联网框架中常见功能，并且对源代码自己有必定侵入性。
三、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上。
四、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是拆箱即用，不用单独维护，不须要作任何源程序的逻辑修改，能够实现分布式配置各类功能。
五、总结
当然分布式架构相比于单体应用要复杂不少，可是随着服务自己的复杂度增长，单体应用由于模块划分不清晰常常为修改一个很小的功能而牵一发动全身，再加上IT行业人员流动性比较大，就形成了咱们在修改项目架构和转型的阵痛中不断翻转。微服务大大增长了开发工做量并要求开发人员必需要掌握某种RPC技术，RPC在实际通讯过程当中产生的各类底层问题更是让人难以捉摸。如今以Kubernetes为表明的第一台容器基础架构出现了，旨在解决下降服务与服务之间的调用问题，让应用更有弹性、容错性、观测性的基础技术，让应用更容易部署、管理、交付的基础软件、可是前期须要投入大量学习和试错成本，固然任何技术都有两面性，存在优势的同时必然存在缺点，这就要根据实际状况作出选择了。
提早祝你们2020年：
雾霾都散去
好事都到来
逝者不可追
来者犹可期
原创不易，随手关注或者”在看“，诚挚感谢！
推荐阅读：
Kubernetes中如何使用ClusterDNS进行服务发现？
本文分享自微信公众号 - 云原生技术爱好者社区（programmer_java）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。