什么是微服务架构？
微服务(MicroServices)架构是当前互联网业界的一个技术热点，业内各公司也都纷纷开展微服务化体系建设。微服务架构的本质，是用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。该架构强调的一些准则：单一职责、协议轻量、进程隔离、数据分离、独立部署、按需伸缩。
什么是Kubernetes？
Kubernetes是Google开源的容器集群管理系统，其提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用，其主要功能：1) 自动化容器的部署和复制，随时扩展或收缩容器规模。2) 以集群的方式运行、管理跨机器的容器。3) 将容器组织成组，并且提供容器间的负载均衡。4) 解决Docker跨机器容器之间的通讯问题。5) Kubernetes的自我修复机制使得容器集群保持健康状态。
微服务架构（MSA）跟SOA架构有何不同？
微服务架构是伴随敏捷迭×××发而兴起的，更加强调快速敏捷部署和伸缩，适用于功能拆分比较细的场景，粒度也更小、更独立。协议上基于更加轻量化的REST API，供内部各子系统及微服务之间调用。适合业务相对独立、简单的互联网场景。强调服务的独立部署和易伸缩能力。下图是详细的对比：
怎么理解服务注册和服务发现？
微服务架构下，有大量的微服务需要处理。由于微服务的快速和敏捷研发，他们的位置可能会动态变化。因此在运行时需要能够发现服务所在的位置，服务发现可以解决这个问题。
服务注册：注册中心有微服务的实例和位置信息，微服务在启动时向注册中心注册自己的信息，关闭时注销。其它使用者能够通过注册中心找到可用的微服务和相关信息。
服务发现：为了能找到可用的服务和他们的位置信息，需要服务发现机制。有两种发现机制，客户端发现和服务端发现。WEB应用中，比较常用的是服务端发现的方式：客户端/API网关把请求发送到已知位置信息的组件（比如负载均衡器）。组件去访问注册中心，找到微服务的路径信息，并跳转到相应的微服务。
云运维平台如何基于Kubernetes实施微服务？
基于平台的微服务部署变得不同于传统模式：能够独立于其他微服务发布或者取消发布； 微服务可以水平扩展（某一个服务比其他的请求量大）；能够实现快速的构建和发布；各微服务之间的功能不相互影响。使用基于Kubernetes的方式部署微服务，用户需要的只是定义服务的状态，而不是部署过程。
先来看一下Kubenetes整体框架，如下图所示：主要包括kubecfg、Master API Server、Kubelet、Minion以及Proxy。
Master定义了Kubernetes 集群Master/API Server的主要声明，包括Pod Registry、Controller Registry、Service Registry、Endpoint Registry、Minion Registry、Binding Registry、REST Storage以及Client, 是client(Kubecfg)调用Kubernetes API，管理Kubernetes主要构件Pods、Services、Minions、容器的入口。 Minion负责跟踪Kubernetes 集群中有多少台主机。Pod负责跟踪集群中有多少Pod在运行，及跟Minion的映射关系。
下面我们一起看下，基于Kubernetes是如何进行服务注册发现的，其详细的架构如下图所示：
Kubelet是Kubernetes集群中每个Minion和Master API Server的连接点，Kubelet运行在每个Minion上，是Master API Server和Minion之间的桥梁，接收Master API Server分配给它的commands和work，与持久性键值存储etcd、file、server和http进行交互，读取配置信息。Kubelet的主要工作是管理Pod和容器的生命周期，其包括Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client以及Health Checker组件。
部署完毕后的Kubernetes集群，其各组件和微服务架构所提出的一些准则的对应关系，如下图所示：
应用以Docker容器的形态，通过Namespace隔离的运行在定义好的Pod当中，各微服务之间的调用变得如此简单，再也不用为微服务的实施和治理烦恼了。
原文地址：http://blog.51cto.com/14084875/2336085