目录

容器

Kubernetes

服务网格

---

 

软件正在改变传统的业务模式，嘀嘀打车、Airbnb、Amazon、Netlifx等正在颠覆一个个传统行业。IT部门不再是站在业务后面的支撑部门，而是成为了互联网时代企业的核心竞争力，为了充分满足内部用户和客户需求，如今的企业必须部署和运行相应的业务应用，甚至那些过去认为自己与软件业务完全不相干的公司也是如此。

软件正在吞噬整个世界
“越来越多的主流企业和行业领域，从电影业到农业再到国防业，他们都在依靠软件产品实施业务运作和提供在线服务。”
- Marc Andreessen

为了适应新时代需求，应用的架构也需要进化，新架构要有能力应对未来快速变化的环境，能从功能上和性能上灵活扩展。微服务架构就是在这个背景下出现的。每种新的技术都是为了解决一个或者多个特定的问题，微服务架构也不例外，它可以避免单体应用所存在的缺陷，因为不同服务之间的交互界面更加简洁，开发人员可以根据需求随时对每个微服务进行更改。

那么企业应用采用微服务架构有什么工具和最佳实践呢？本文介绍以下三种微服务落地的利器，它们能在不同阶段帮助企业解决微服务实施过程中遇到的问题。

容器

最近一段时间内容器技术发展迅速，成为了各种技术论坛和社区活动中最活跃的话题。容器技术解决了什么问题，使它在短时间内爆发式的流行起来呢？这个需要我们从应用的架构的发展过程中找到答案。

IT架构演化

• 应用架构。从运行在大机上的单体式应用，到运行在x86服务器山的多层结构应用，再发展到目前非常流行的微服务概念。虽然真正的微服务应用实际落地的案例还非常有限。
• 开发流程。从传统的瀑布式的开发模型，到敏捷开发的引入，再发展为覆盖整个软件生命周期的Devops方法。
• 部署方式。从传统的私有数据中心部署，到应用上公有云、私有云，再发展为跨云部署。

以上的一些技术和概念其实很早就提出了，但是一直发展的不温不火，比如Devops的概念是2009年提出的，微服务的概念2012年就有了。直到有一天，容器技术开始流行，人们发现，容器技术是Devops、微服务以及跨云部署的最好的技术载体。

• 采用微服务架构，一个应用可能被划分为多个细粒度的服务，每个服务可以使用不同的开发语言和框架，这给应用的部署和管理提出了巨大的挑战，运维人员需要熟悉不同框架的部署流程、环境依赖以及运维方法。而通过使用容器技术，每个微服务的交付物被统一成一个格式，在隔离的环境中运行，容器内部的环境和依赖交给应用开发人员来处理。所以说，容器加速了微服务的落地。
• 而容器和Devops更是天作之合，容器可以屏蔽开发与运维之间的环境差异；可以在Devops的pipeline（开发测试、staging和生产）之间无缝的流转；通过Dockerfile实现的基础设施即代码的功能使Devops的整个流程完全自动化；快速启动的特性刚好配合了Devops早发布常发布的原则。
• 从应用部署环境来看，单体式的应用很难迁移，一旦上线运行可能若干年都不会更新或者迁移。基于虚拟机的应用在这方面有所改进，可以进行不同环境的迁移，但是由于基础设施所支持的虚拟机格式的不同，迁移成本很大，比如从vSphere迁移到Openstack或者aws环境，需要进行虚拟机格式的转换。而基于容器的应用可以在不同的虚拟化和云环境中快速迁移，与一些其他技术比如SDN、Golbal load balance配合，更可以实现跨云的部署。

容器作为落地载体

Kubernetes

容器技术的成熟直接促进了微服务的发展，作为微服务运行的载体，很好的解决了微服务部署和隔离的问题。但是一个大型的应用通常有十几个甚至几十个微服务、上百个容器组成。大规模容器的管理、监控和调度就成了问题。Kubernetes可以很好的解决这些问题，它有丰富的调度策略，内置了容器的监控和管理功能，统一的网络和存储接口帮助应用有效的屏蔽了基础设施相关的工作。从这个层面来说，Kubernetes很好的提供了微服务的运行环境。但是这些都只是微服务应用运行的最基础条件，还远远不能满足微服务运维和治理高级需求。有没有一种技术可以更好的整合容器和Kubernetes，使业务更快的上线，给开发人员更多的选择权，让运维人员灵活的管理系统呢？
Kubernetes在这个方向上迈出了第一步，它抽象出Service的概念作为微服务，使用Kubeproxy和Ingress做为内外的负载均衡，每个Service自动注册到Etcd，通过Service 名称可以获取调用地址。Kubernetes提供了微服务应用的最基础的几个功能，但是这些功能离实际需求还是相差的太远，很多在生产环境中所需要的服务治理功能都没有，如服务管理、部署、版本控制、安全、熔断限流，以及一些复杂部署功能如A/B测试、金丝雀发布、智能路由、访问控制等。当然了，作为一个容器调度框架，而非微服务框架，对Kubernetes的要求有些苛刻了。那么这些微服务相关的功能应该由谁来提供呢？这就要说到我们下文要提出的服务网格方案了。

服务网格

微服务和容器改变了应用架构和部署的方式。我们知道，微服务通过对复杂系统进行拆分，使其变成多个易于开发和维护的小的服务单元，每个单元保持自身的开发和发布节奏，从而实现敏捷性。但是微服务拆分以后也带来了分布式系统的复杂性，原本进程内部的调用都变成了远程调用，一些简单事务也变成了分布式事务，同时还需要考虑服务之间的调用管理（权限、熔断、限流、灰度等）、每个服务的监控、整体业务的分布式追踪等内容。

为了解决以上的一些分布式系统治理的问题，一些微服务的框架应运而生，比如Spring cloud、dubbo等。这些框架提供了微服务治理过程中所需要的功能和工具，比如服务的注册和发现、熔断限流、API网关、路由和负载均衡以及配置管理等。但是这类框架最大的问题是过于复杂，每个细分的功能都会引入一个工具，对于开发和运维人员来说需要掌握太多的工具，学习曲线很高。以Spring Cloud为例，涉及到微服务治理的工具有以下这些:

Spring Cloud Main	Spring Cloud Netflix
Spring Cloud Config	Eureka
Spring Cloud Bus	Hystrix
Spring Cloud Data Flow	Turbine
Spring Cloud Consul	Atlas
Spring Cloud Security	Feign
Spring Cloud Sleuth	Ribbon
Spring Cloud Task	Zuul
Spring Cloud Zookeeper	Archaius

这给应用开发人员造成了困扰，需要太多的时间去熟悉不同工具的使用方法。对于业务部门来说，微服务是手段而不是目标，开发人员应该将更多的精力投入到业务逻辑的开发中去，而不是学习和实现微服务。另外需要提出的是，目前大多数微服务框架都很难跨语言，比如Spring Cloud主要是支持Java语言的。这也违背了微服务可以使用任意语言开发的初衷。更重要的是，这些微服务框架都是侵入式的，也就说你在代码开发的时候就需要在代码中嵌入和工具相关的内容，这位以后应用的迁移、改造和升级制造了很多困难。

服务网格（Service Mesh）就是在这种背景下提出的概念，而istio就是目前最流行的服务网格解决方案。istio是由Google、IBM和Lyft联合推出的开源项目，它和Kubernetes一脉相承，在发布初期就被吸收为CNCF的项目。

Istio提供一种简单的方式来建立已部署的服务的网络，具备负载均衡，服务到服务认证，监控等等功能，而不需要改动任何服务代码。

Istio服务网格逻辑上分为数据面板和控制面板。

• 数据面板由一组智能代理（下图中的Envoy，也可用其他项目替换）组成，使用sidecar模式部署，调解和控制微服务之间所有的网络通信。
• 控制面板负责管理和配置代理来管理路由流量，以及在运行时执行特定策略。

Istio逻辑结构

目前和istio结合最紧密的是Kubernetes，Istio在同一个POD的应用容器旁边注入一个sidecar容器，这个sidecar起到一个类似代理的作用，将服务之间调用的治理逻辑和功能完全接管。这样的好处是处理业务逻辑的容器完全不需要考虑微服务治理的功能，代码只和业务相关。另外一个好处是在微服务治理过程中的规则和逻辑可以随时调整，由istio的控制面下发规则到sidecar容器。由于服务之间调用采用标准的网络协议，和语言无关，业务容器和sidecar容器独立存在，所以每个微服务可以根据需要选择开发语言。提到POD，大家都知道这是个Kubernetes的特有概念，Kubernetes在设计之初就支持同一个POD内部可以运行多个容器，现在看来这个设计真是具备非常超前的想象力，也让人不得不佩服Google在这个领域深厚的功力。

Istio的目标是以后脱离Kubernetes成为一个中立的service mesh框架，支持更多的微服务环境。使用istio可以满足微服务治理过程中大部分的功能需求，比如上文提到的服务注册和发现、智能路由、负载均衡、权限管理、限流断路、灰度规则等，还可以收集日志、监控和分布式追踪的信息。在这个体系架构下，开发人员可以最大限度的关注业务逻辑，而运维人员可以灵活的调整服务的部署和调用策略。

---

从技术的发展趋势看来，要实现灵活的微服务架构，容器-->Kuberntes-->服务网格是一条比较快速和稳妥的路线，用户可以逐步掌握新的技术，不断扩大使用场景。如果说容器和Kubernetes使越来越多的企业开始使用Devops和微服务，那么服务网格可以使大家用好Devops和微服务。