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

本文是 Choerodon 猪齿鱼微服务系列文章的第一篇，在文章中将介绍当前比较流行的两种微服务架构，即 Dubbo 和 Spring Cloud，同时将总结 Choerodon猪齿鱼在选择使用微服务架构中的一些实践经验，希望能够给大家一些借鉴和启迪。

▌文章的主要内容包括：

• 什么是微服务架构
• Dubbo 的诞生背景
• Spring Cloud 应运而生
• Kubernetes + Docker使微服务实施成为一种可能
• 微服务“新秀”——Service Mesh

在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微服务实战》

在传统的单体应用系统架构中，一般分为三个部分，即数据库、服务应用端和前端展现，在业务发展初期，由于所有的业务逻辑在一个应用中，开发、测试、部署都比较容易。但是，随着业务的发展，系统为了应对不同的业务需求会不断为单体应用增加不同的业