Choerodon的微服务之路(一)：如何迈出关键的第一步

在Choerodon猪齿鱼设想之初，咱们但愿基于容器技术，整合DevOps工具链、微服务应用框架，开发一个企业级的PaaS平台，来帮助企业实现敏捷化的应用交付和自动化的运营管理。同时，也肯定了技术堆栈的要求，即充分地使用主流成熟的开源组件，利用开源工具的扩展机制来构建平台，打造一个开放的技术平台和体系，让企业享受到开源社区的成果。

固然，罗马不是一天建造起来的。从初期肯定技术栈到如今，除Choerodon猪齿鱼平台具体应用的实践与迭代，平台的技术栈也在不断进行着迭代。在开源社区中解决一个相同问题的开源技术有不少，而如何验证甄别哪些开源技术既可以知足如今的系统需求，在将来又有比较好的适应性，就给广大的架构师和软件设计师提出了挑战。根据Choerodon猪齿鱼实践经验，在使用开源技术时，能够从以下几个方面来进行考虑：

• 语言 - 选择开源技术一个很是核心的考量是尽可能使用应用比较普遍的开发技术，避免涉及相对来讲的新技术、开发语言，这样能够进一步研发下降成本。例如Java的使用很是普遍。
• 成熟度 - 开源技术的版本是否已经发布稳定版本或者更高版本是其成熟的重要标志，例如Istio在8月发布1.0版本，促使了很过公司和产品跟进使用；若是产品仍处于孕育阶段，则其技术变动的风险就比较大，例如 Apache 的 incubating 、 0.XXX版本或者beta版本等都有可能有各类技术缺陷或者没有通过较好的实际检验。
• 社区 - 开源社区的活跃度在必定程度上反映了整个技术的生命力，例如是否有大量相关社区存在，K8s在国内就有Kubernetes中文社区，K8s中文社区等，以及按期还有各类关于K8s的Meetup或者论坛等；固然GitHub 上的 stars 的数量是一个参考指标，以及贡献者数量、代码更新频率等。
• 生态圈 - 围绕开源技术是否有活跃健康的生态圈，是否有比较多的用户在使用，尤为是一些大公司，以及围绕开源产品是否有较多的文章、知识分享，或者围绕产品的某一块功能第三方加强开源工具，例如围绕Hadoop有Sqoop、Hbase、Hive等。
• 文档 - 完备并及时更新的文档，很是有利于用户了解开源产品的设计思路、安装、使用等，方便产品在用户这边落地实践。想一想 sourceforge.net 上现在已经是代码的坟墓，没有文档的代码生命周期一般都不长。
• 资源 - 开源技术若是在业界比较高的人气，应该有比较多的使用者，市场上相关人员资源也很是丰富，比较有利于团队技术人员的补充。

到目前为止，Choerodon猪齿鱼通过不断地迭代，逐渐造成了以 Spring Cloud + Kubernetes 为主体的微服务技术体系。

什么是微服务架构

在开始介绍以前，首先须要了解什么是微服务架构？ 2014年初（该年能够称之为微服务的元年），微服务之父 Martin Fowler 在其博客上发表了"Microservices" 一文，文中正式提出了微服务架构风格，并指出了微服务架构的一些特色。

简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个本来独立的系统拆分红多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间经过基于HTTP的RESTful API进行通讯协做。被拆分的每个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，而且每一个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。因为有了轻量级的通讯协做基础，因此这些微服务可使用不一样的语言来编写。

-- 做者 James Lewis and Martin Fowler， 翻译自《Spring Cloud微服务实战》

在传统的单体应用系统架构中，通常分为三个部分，即数据库、服务应用端和前端展示，在业务发展初期，因为全部的业务逻辑在一个应用中，开发、测试、部署都比较容易。可是，随着业务的发展，系统为了应对不一样的业务需求会不断为单体应用增长不一样的业务模块。长此以往，不断扩充的业务需求致使单体应用的系统愈来愈庞大臃肿。此时，单体应用的问题也逐渐显现出来，因为单体应用是一个“总体”，每每修改一个小的功能，为了部署上线就会影响到其余功能的运行。并且，对于业务而言，每每不一样模块对系统资源的要求不也尽相同，而单体应用各个功能模块由于没法分割，也就没法细化对系统资源的需求。因此，单体应用在初期是比较方便快捷，可是随着业务的发展，维护成本会愈来愈大，且难以控制。

Martin Fowler 认为微服务架构与单体应用最大的区别在于，微服务架构将一个完整的单体应用拆分红多个有着独立部署能力的业务服务，每一个服务可使用不一样的编程语言，不一样的存储介质，来保持低限度的集中式管理。下面这张图，很好的说明了单体架构和微服务架构的区别。

根据 Choerodon 猪齿鱼的开发实践和产品化经验，在互联网+、云计算和大数据、人工智能等的大背景下，构建软件系统产品，首先要把系统的基础框架搭好，方便后续的扩展。而微服务架的独立部署、松耦合等特色，与Choerodon猪齿鱼的想法和设计理念不谋而合， 因此 Choerodon 最终选择了微服务架构做为基础架构。

而在微服务基础框架中，有两个不得不提的微服务架构，分别是阿里巴巴的 Dubbo 和 Pivotal 公司开源的 Spring Cloud 。

Dubbo的诞生背景

Dubbo 是一个高性能、基于JAVA 的开源RPC 框架。阿里巴巴开源的 Dubbo 致力于提供高性能和透明化的RPC 远程服务调用方案，以及SOA 服务治理方案，使得应用可经过高性能RPC 实现服务的输出和输入功能，和 Spring 框架能够无缝集成。本质上而言，是一个服务框架。根据Dubbo 的官方 Roadmap 能够看到，Dubbo 的发展经历了以下几个过程：

• 数据访问框架(ORM)：早期的主流开发方式是面向对象的开发方式。只需一个应用，将全部功能都部署在一块儿，以减小部署节点和成本。关系数据库是企业级应用环境中永久存放数据的主流数据存储系统，简化了增删改查工做量。
• Web框架(MVC)：随着访问量逐渐增大，单一应用已经没法知足业务需求，将应用拆分红互不相干的几个应用，分离视图层和业务逻辑层以提高效率。
• 分布式服务框架(RPC)：当垂直应用愈来愈多，应用之间交互不可避免，将业务抽取出来，做为独立的服务，逐渐造成稳定的分布式服务架构。
• 面向服务的架构(SOA)：当服务愈来愈多，业务和环境的变化愈来愈快时，对于资源的控制，性能的要求也就愈加重要。SOA 将一个应用程序的业务逻辑或某些单独的功能模块化并做为服务呈现给消费者或客户端，使得业务IT 系统变得更加灵活。

Dubbo 按照分层来规划咱们的系统，包含远程通信、集群容错和自动发现三个核心部分。提供透明化的远程方法调用，使各个服务之间解耦合，并经过RPC的调用来实现服务的调用。

Dubbo 因为自身的设计使得服务之间的调用更加透明，网络消耗小，同时借助相似zookeeper 等分布式协调服务实现了服务注册。可是Dubbo 的缺点也是显而易见的，好比：

• 只支持JAVA 使得Dubbo 在开发语言上受到了限制
• 虽然RPC 相对于HTTP 而言性能更高，可是在网络通用性上却有着局限性
• 并且对于一个微服务架构而言，包括服务网关，配置中心等不少东西都是缺失的，须要本身实现
• 虽然Dubbo 很早就进行了开源，可是在很长一段时间官方都没有对开源版本进行维护

因为这些缺点，Choerodon 并无选择 Dubbo 做为基础开发框架。

Spring Cloud 应运而生

在微服务架构的概念提出以后，很快 Netflix 公司将自家通过多年大规模生产验证的微服务架构，抽象落地造成 一整套开源的微服务基础组件 NetflixOSS 。2015年，Pivotal 将 NetflixOSS 开源微服务组件集成到其 Spring 体 系，并推出 Spring Cloud 微服务开发技术栈。自此，微服务技术迅猛普及，甚至 Spring Cloud一度成为了微服务的代名词。

可能更多了解微服务架构的读者都是从 Spring Cloud 入门，凭借以前 Spring Framework 的良好群众基础和Cloud 这个具备时代感的名字，Spring Cloud 的名字能够说是无人不知，无人不晓。结合Pivotal 公司的 Spring Boot，咱们经过封装开源成熟的Spring Cloud 组件和一些基础的分布式基础服务，就能够简单快速的实现一个微服务框架，下降应用微服务化的门槛。

Spring Cloud 提出了一整套有关于微服务框架的解决方案。包括：

• 服务注册发现：Spring Cloud Eureka
• 负载均衡：Spring Cloud Netflix
• 服务网关：Spring Cloud Zuul
• 配置管理：Spring Cloud Config
• 服务消费: Spring Cloud Ribbon/Feign
• 分布式追踪：Spring Cloud Sleuth
• 服务容错：Spring Cloud Hystrix
• ...

下图说明了借助Spring Cloud 搭建的一套简单的微服务体系。

能够看到，Spring Cloud 集成了众多组件，从技术架构上下降了对大型系统构建的要求，使架构师以很是低的成本（技术或者硬件）搭建一套高效、分布式、容错的平台。但同时，在实际开发中也发现 Spring Cloud 存在着的一些问题：

• 技术要求高：Spring Cloud 对于配置中心、熔断降级、分布式追踪、在权限认证、分布式事物等基本的功能，并无提供一个成熟的组件，须要结合第三方的组件或自研实现。这对整个开发团队提出了很是高的技术要求。
• 代码侵入性强：Spring Cloud 对业务代码有必定的侵入性，技术升级替换成本高，致使实施团队配合意愿低，微服务落地困难。
• 服务运维困难：Spring Cloud 在服务调度和部署、服务日志、服务监控等仍有缺失。当服务的规模增大，对于微服务的管理有可能会增长运维的负担。
• 多语言支持不足：对于大型公司而言，尤为是快速发展的互联网公司，企业的性质决定了多语言的技术栈、跨语言的服务调用也是常态，跨语言调用也偏偏是微服务概念诞生之初的要实现的一个重要特性之一。

Dubbo & Spring Cloud 对比

对比Dubbo 和Spring Cloud 能够发现，Dubbo 只是实现了服务治理，而Spring Cloud 的子项目则分别覆盖了微服务架构下的众多组件，而服务治理只是其中的一个方面。

经过谷歌和百度的搜索统计能够看到，自2015年起到如今，国内对于Spring Cloud 检索指数也在逐渐赶超Dubbo。

综合而言，Dubbo专一于服务治理；Spring Cloud关注于微服务架构生态。

虽然 Spring Cloud 下降了微服务化的门槛，可是除了基础的服务发现之外，Choerodon 团队在实际开发中也遇到了诸多的挑战。例如，各个组件并不是天衣无缝，不少组件在实际应用中都存在诸多不足和缺陷。 Spring Cloud 并非银弹，微服务架构解决了单体系统变得庞大臃肿以后产生的难以维护的问题，可是也由于服务的拆分引起了诸多本来在单体应用中没有的问题，好比部署困难，监控困难，运维成本大，是选择 Spring Cloud 首先要面对的问题。

而容器化的普及，尤为是云原生技术生态的不断完善，比较好地解决了微服务架构的采用引起的诸多问题，使得微服务在普通传统企业的落地成为了可能。

Kubernetes + Docker 使微服务实施成为一种可能

当企业逐步接受微服务架构，享受着微服务带来好处的同时，也面临着微服务运维成本的增长， 环境的不一致，服务的编排、部署、迁移等诸多问题。Choerodon 平台通过不断地演进，从初期引入Docker，到Rancher + Jenkins，再到如今采用 Kubernetes 为容器编排和管理工具。

容器技术产生的主要缘由，并非由于资源浪费。主要是开发和运维人员环境不一致，致使开发效率大大下降。经过容器能够在一个彻底隔离的环境中很是高效地运行代码，容器化自然适用于微服务，改善了引入Spring Cloud 微服务后开发效率大大下降的问题。可是单独使用Docker 并无完整的解决微服务管理的痛点，服务的部署和运维仍然急需解决。

Kubernetes 是谷歌推出的容器编排引擎，是基于GoLang 实现的一个开源软件。K8s（Kubernetes）初源于谷歌内部的Borg，提供了面向应用的容器集群部署和管理系统，其目标旨在消除编排物理/虚拟计算、网络和存储基础设施的负担，并使应用程序运营商和开发人员彻底将重点放在以容器为中心的原语上进行自助运营。

早期你们对于K8s 定位是容器编排引擎，同一时期流行的容器编排引擎还有MESOS、Docker Swarm 等。可是通过几年的发展，K8s 已经成为了云供应商的通用基础设施，咱们熟悉的Google Cloud，AWS，Microsoft Azure，阿里云，华为云等等，都提供了对K8s 的支持。如今，K8s 已经不只仅是一种工具，更多的是做为微服务架构的一种行业标准。

下图经过使用微服务架构的设计思想来看待K8s，并对K8s 中的一些功能进行了说明。

经过对比能够看到，在设计上，K8s自己就属于微服务架构的范畴。这里有的人可能就会有疑问，既然 K8s 功能这么强大，那么K8s 和 Spring Cloud 到底哪一个更好？Choerodon 为何不直接使用Kubernetes 做为基础的微服务架构呢？

为了区分Spring Cloud 和Kubernetes 两个项目的范围，下面这张图列出了几乎是端到端的微服务架构需求，从底层的硬件到上层的 DevOps 和自服务经验，而且列出了如何关联到Spring Cloud 和Kubernetes 平台。

能够看到：

• Spring Cloud：自上而下，面向开发者，从应用代码到微服务架构的方方面面
• Kubernetes：自下而上，面向基础设施，试图将微服务的问题在平台层解决，对开发者屏蔽复杂性

综上对比，K8s 遵循了微服务架构的基本核心要素，虽然在一些功能上有所欠缺，但不能否认，K8s 帮助补足了使用Spring Cloud 所缺失的一部分。

微服务“新秀”--Service Mesh

Choerodon 经过使用 Spring Cloud + Kubernetes 的模式，帮咱们可以很容易的构建和部署微服务架构。可是在线上管理整个微服务体系的时候，仍然面临着一些难点。

一直以来都存在一个谬误，那就是在分布式系统中网络是可靠的。实际上网络是不可靠的，也是不安全的，微服务中大部分的故障都是出如今服务通讯中。

K8s 帮咱们实现了微服务的部署，但服务的网络调用、限流、熔断和监控这些问题，依旧让开发和运维人员都十分头痛。如何保证应用调用和事务的安全性与可靠性？Service Mesh 由此应运而生。

在过去几个月里，Service Mesh是行业内毋庸置疑的焦点。Service Mesh 译做“服务网格”或“服务栅格”，做为服务间通讯的基础设施层。Service Mesh 是一种模式，而非技术。Buoyant 公司的 CEO Willian Morgan 在他的文章《WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?》中解释了什么是 Service Mesh。

A service mesh is a dedicated infrastructure layer for handling service-to-service communication It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.*

Service Mesh 本质上是一个轻量级的网络代理，比如应用程序或者说微服务间的 TCP/IP。

对于开发人员而言，在编写应用的时候无需关心网络这一层，使得服务回归到本质，专一于业务功能，服务中的交互则交给Service Mesh。Service Mesh 为服务提供了一个视图，提升了追踪能力，并提供了添加跟踪而不触及全部应用的能力，也就是所谓的Service Mesh 代码无侵入和透明性，可以帮助团队更好地管理服务。

Service Mesh 架构图：

能够看到，Service Mesh 经过一种Sidecar的模式。给每个微服务实例部署一个Sidecar Proxy。该Sidecar Proxy 负责接管对应服务的入流量和出流量，并将微服务架构中的服务订阅、服务发现、熔断、限流、降级、 分布式跟踪等功能从服务中抽离到该Proxy 中。

Sidecar 以一个独立的进程启动，能够每台宿主机共用同一个Sidecar 进程，也能够每一个应用独占一个Sidecar 进程。全部的服务治理功能，都由Sidecar 接管，应用的对外访问仅须要访问Sidecar 便可。当该Sidecar 在微服务中大量部署时，这些Sidecar 节点天然就造成了一个服务网格。

经过控制面组件对这些服务网格进行管理，这样也就提供了一种对于微服务进行高效而统一的管理方式。集中化的控制面板，同时仍然具备为所欲为的敏捷性和基于云的应用开发。这一特性，使得Service Mesh 成为大势所趋。

总 结

回顾微服务结构发展的这几年，微服务架构的逐渐普及，容器技术的兴起，云原生的趋势，微服务技术生态在不断地变化中，容器、Cloud Native、Serverless、Service Mesh，Knative 等新技术新理念你方唱罢我登场，使得整个以微服务为核心的生态愈来愈完善成熟。

像在前文中提到的Kubernetes、Service Mesh等都是解决微服务架构自己系统范围的问题，扎实可靠的基础框架，有利于后续的开发，这也是产品研发、系统实施的关键第一步。

除了系统自己的技术栈，工程落地实施是另外一个要解决的问题。不少产品开始开发的时候，都不太注意规范化，待产品需求愈来愈复杂，人员愈来愈多时，整个项目会变得很难维护，甚至会影响产品的持续迭代。特别是微服务技术体系的引入，这个问题会更加明显。因此若是项目一开始，就以工程化的思想去组织代码，以规范化的流程去作构建发布，会给后续的发展打下坚实的基础。微服务的工程落地实施是Choerodon猪齿鱼一直关注和实践的方向，经过整合DevOps工具链和引入落地敏捷实施的方法论，让微服务架构的工程落地变得容易，这也成了Choerodon的PaaS平台能力，在这就不作赘述，感兴趣的读者能够到Choerodon的官网了解。

---

关于猪齿鱼

Choerodon 猪齿鱼做为开源多云应用敏捷全链路技术平台，是基于开源技术Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。平台经过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。

更加详细的内容，请参阅Release Notes和官网。

你们也能够经过如下社区途径了解猪齿鱼的最新动态、产品特性，以及参与社区贡献：

• 官网：http://choerodon.io
• 论坛：http://forum.choerodon.io
• Github：https://github.com/choerodon

欢迎加入Choerodon猪齿鱼社区，共同为企业数字化服务打造一个开放的生态平台。

本篇文章出自 Choerodon猪齿鱼社区董凡。