简单来说，微服务是将大型单体应用程序和服务拆分为数个甚至数十个微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。然而，这个过程涉及很多问题需要解决，比如拆分原则、容量规划、组件选择、服务治理甚至人员配比等。本文，Pivotal 云平台资深架构师刘凡将详细讲解从 Java 开发者转型微服务这些年所做的思考。
根据维基百科定义，微服务不是整体应用程序中的一个层。相反，微服务是一个独立的业务功能，具有清晰的接口，并且可以通过内部组件实现分层架构。从战略角度来看，微服务架构基本上遵循“做一件事，就要做得好” 的Unix 哲学。为了应对传统单体架构的缺陷，微服务架构被企业广泛应用。然而，实践之前有很多问题都需要提前考虑清楚，比如 Java 背景的开发者是否更有优势？微服务、容器化、DevOps 和 CI/CD 之间的关系？如何合理进行微服务拆分、服务治理、容量规划以及人员分配？
众所周知，Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台，目前最流行的微服务框架 Spring Boot 和 Spring Cloud 正是 Pivotal 的技术。本文，InfoQ 有幸对 Pivotal 云平台资深架构师刘凡进行了独家采访，了解他在转型微服务过程中所做的思考。
如果简单总结微服务的概念，刘凡认为，微服务是一种架构模式，是业务领域组件模块的集合。通过轻量级的通信方式和比较灵活的聚合方式，微服务组合在一起，借助持续集成、持续交付等工具实现独立部署。
作为一名曾经的 Java 开发者，刘凡的微服务之旅是从PiggyMetrics开始的。这是 GitHub 上一个不错的开源项目，通过此项目学习使用 Docker 和 Spring Cloud 如何做分布式微服务架构。他认为，微服务架构并不与具体编程语言绑定。回顾整个转型过程，从分布式应用开发转为微服务架构属于业务的自然发展驱动，当业务发展到一定阶段，自然就出现上云诉求，需要对应用架构进行更新换代。虽然 Java 不是微服务开发的唯一选择，但这是大多数企业应用开发选用的编程语言（占比达到 80% 以上），其本身的企业级应用生态也比较完善和成熟。目前很多主流微服务框架均基于 Java 实现，但这并不是强绑定的关系，企业实践微服务更多是为了解决业务层面的问题。那么，当业务出现哪些问题或者发展到哪一阶段是实践微服务的最佳时间呢？
关于此，业内曾有专家提出过比较简单的判断方式：当单体应用同时进行开发的人数超过 10 人就证明是时候进行微服务拆分了。刘凡表示，10 人以下的团队人数是基于现代应用使用敏捷过程组建团队比较合适的规模，但如何拆分应用以及相配套的团队规模，仍然需要通过业务复杂度和团队技术储备来确定。另一方面，微服务并不能解决企业所有的 IT 系统问题，尤其是信息化程度较为落后的企业可能得不到太多好处。大部分企业都是基于业务驱动选择微服务架构，刘凡谈到，这种驱动可以大致分为两类：一是应对业务的快速变化，企业需要构建快速响应业务需求的能力，发布更多创新型云原生应用来提升用户体验和响应市场变化，通过敏捷开发流程满足客户所需；二是既有系统的云化改造，企业首先已经认可了云平台带来的类似弹性、安全、可靠性等优势。由于传统单体应用的运维模式给企业带来很多困扰和大量的成本花费，企业希望通过运维转型来缩短发布周期，降低投资风险，从而提高企业核心竞争力。微服务改造是实现这一切的前提。
具体来说，一旦单体应用被划分为多个小模块，投资风险就会随之降低，业务创新更易付诸实现。其次，微服务本身与容器、DevOps、CI/CD（持续集成 / 持续交付，文末附介绍）以及云平台并不是割裂的，这些因素都会影响企业应用系统的云化改造。刘凡介绍，微服务和容器本身是两种技术，但容器可以让微服务更快交付（微服务容器化），并保证可重复的、一致的交付体验；DevOps 更多是强调流程和方法论，通过自动化的交付工具链实现 CI/CD，缩小开发和运维之间的界限，当然这不等于让开发做运维的工作，或者让运维做开发的工作，只是让双方协作更为通畅。
如上可见，这些概念本身是相互独立的，但云原生（Cloud Native）的思想却可以把他们概念联系在一起。早在 2015 年，Pivotal 公司的 Matt Stine 写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征：
当然，这不代表所有的云原生应用必须具备这些特征，但这是 Pivotal 当时对云原生应用最佳实践的定义（随后，CNCF 进行了重新定义，但依旧包含这些技术要素），这就验证了前文所述为什么企业应用上云时会进行微服务改造，甚至容器化等，只有符合最佳实践的应用才可以达到更好的资源配置、更优的性能以及更快速、完美的交付运维体验。
这样看来，微服务实践并不是仅与架构师相关。从开发视角来看，企业可以拥有更为独立的开发团队，开发人员只需关注业务本身，维护很小的代码仓库即可，不需要像传统单体应用那样维护应用间的诸多依赖，尤其是解决上线过程的很多代码冲突；从运维视角来看，微服务会用到敏捷开发，包括 DevOps 方法论和实践，通过 CI/CD、数据集成等工具提速交付过程，降低上线风险和压力。
Spring Cloud 和 Spring Boot 是目前最受开发者关注的两大微服务框架，大部分开发者认为这二者非常相像，做的事情也比较类似。在刘凡看来，Spring Boot 更倾向于微服务的最终实现手段，而 Spring Cloud 则是微服务治理方案。从传统的单体应用转变为微服务，这个过程会引发很多分布式系统问题，比如微服务需要部署在不同机器上或容器中，以及彼此之间需要互相通信，错误机制，日志的聚合，业务指标度量监控等，这些问题都可以利用 Spring Cloud 进行微服务动态运行时的管理，而业务逻辑的实现都在 Spring Boot 之中。
在了解概念的基础上，企业就可以考虑微服务的具体实施路径。当然，并不存在通用的理想路径，企业需要结合自身情况选择最合适的方法。对于没有历史包袱（老旧系统）的企业，只需按照云原生实践的相关方法论和工具，比如云原生十二要素进行改造即可。对于大型既有系统的微服务改造，刘凡推荐了可能的迁移路径供企业参考：
在这个过程中，企业还需要解决微服务容量规划、服务聚合、服务治理、服务测试等问题。
在容量规划层面，单体应用时代只需针对单个应用的访问量和实际接口性能决定要不要扩容，拆分为微服务之后需要考虑每个服务的容量规划。刘凡建议，整体需要基于服务类型、团队规模和技术栈进行规划。首先，不同的服务类型存在一些标准规则，比如大数据分析引擎可能需要遵循实时数据分析原则；其次，如果团队规模在五到八人之间，微服务不建议拆分得太多，否则运维、管理、更新都很难安排出人手；最后，微服务应用达到一定规模之后就很难通过纯手工的方式进行管理，需要云平台和容器化技术的加入以帮助大容量微服务生命周期管理。
在服务聚合层面，主要涉及微服务的编排或者组合。在某些场景中，拆分后的微服务也需要彼此协作。刘凡表示，这种情况比较推荐常见的典型架构，比如通过 API 网关将微服务接口开放给客户端，客户端选择需要调用的接口根据逻辑拼装好数据，附加上相应的权限能力来访问微服务。同时，也可以选用一些编排工具，比如 Spring 家族里面的 Spring Cloud Data Flow（文末附具体介绍），通过这样的数据和流式编排工具完成微服务之间的组合或者聚合。
在服务治理层面，除了可以通过轻量级通讯协议将内部接口开放给外部系统外，业界目前比较流行的技术还包括 Istio 等。Istio 是一种 Service Mesh 的技术，是一套无代码倾入性的微服务治理且更符合运维人员习惯的解决方案，它使得微服务治理完全放到平台层进而实现全面的 DevOps 成为可能。虽然 Istio 目前还不太成熟，只发布到 1.1 版本。随着越来越多的企业和用户为之贡献，该技术会逐渐走向成熟并最终用于更大规模的生产环境。
在微服务测试层面，刘凡表示，软件工程的质量保证是整个交付过程的重要衡量标准。因此，Pivotal 推行测试驱动的实践方法，通过单元测试覆盖最基础的业务领域功能；在微服务之间会采用 API 接口测试，基于 API 优先的云原生要素，采用如 Spring Cloud Contract 的契约测试方法，或基于 API 文档进行 Mock 测试。在交付阶段，Pivotal 还会进行端到端的测试，而此时需要搭建测试环境。在测试环境搭建和版本升级时，推荐使用回归测试的方法。相较于传统应用的本地环境，微服务通常利用云平台自动化搭建测试环境，根据不同微服务的版本组合提交时会利用蓝绿发布、灰度发布、A/B Testing 等方式进行测试。
在这个过程中，刘凡认为需要重点关注和比较困难的有两点：一是业务与开发人员之间的理解和沟通，这是微服务设计和实践难点。也就是说，开发人员一定要对业务领域和业务逻辑足够清晰，才可能准确、高效得拆分出众多细粒度服务；二是 CI/CD，做微服务一定要做 CI/CD，虽然也有部分企业现在没有做任何的 CI/CD，仅使用手工的方式直接在机器上启动很多微服务实例进程，然后手工运维。并不是说这种方式完全不可取，而是说，随着微服务集群规模的扩大，当达到一定程度后，如果不采用自动化的方式，整个运维工作量会指数级增长，等企业完成整个微服务转型后，就会发现运维成本并没有比传统单体应用时代减少，甚至还增加了很多。因此，CI/CD 是微服务落地非常好的实践，然而 CI/CD 并不仅仅是引入像 Jenkins 或 Concourse 这样的工具就可以达到，还需要企业整个流程甚至组织文化的转型才能实现。
至于整个过程是否需要自建 Kubernetes 集群或者选用自研组件。刘凡表示，微服务框架本身并未与任何平台绑定，因此是否自建 Kubernetes 集群并不是微服务要考虑的核心问题，只要能够运行微服务即可。至于自研微服务框架，目前已经有很多企业通过 Spring Cloud 实现了自研，因为微服务框架本身是一个开放生态，基于数据化需求可能会出现一些较好的自研方案，Spring Cloud 并不与某一个云平台存在绑定关系。但是，自研其实更适合希望了解最新进展或者前人经验的开发者，纯粹因为兴趣爱好学习微服务框架还是可以的；而对于企业而言，因为需要在生产环境运行，所以要考虑稳定性、安全性、可扩展性等问题，对开发团队的要求也比较高，商用化软件平台可能是更好的选择。
除了技术层面做好足够的准备，团队人员配置方面也需要准备好。尽管有非常好的基于领域驱动设计的微服务架构方法论，但团队设计上还是需要考虑匹配开发人员、运维人员、利用自动化交付工具等团队人员。一般情况下，如果一个敏捷团队有 5 到 8 人，每个人管理 2 到 3 个微服务是比较合适的，但随着微服务架构的演进发展，这也需要根据实际情况做出适当调整。
在实践过程中，领域驱动设计（DDD）的思想也非常重要，刘凡在此基础上进行了扩充，比较推荐基于业务逻辑、开发人员技术能力、团队配置以及既有 IT 系统的架构等诸多方面综合考虑，采用持续演进的方式进行微服务设计和开发。领域驱动设计只是指导开发者从业务角度设计一个比较合理的微服务架构，这个微服务架构是否能够适合企业环境，还需要基于更多方面的因素，比如业务逻辑复杂性、团队技术能力等。
Spring Cloud Data Flow
Spring Cloud Data Flow 是一款可自由组合的云原生微服务 ， 用于收集、转化、存储和分析数据。Spring Cloud Data Flow 允许开发人员构建实时批处理应用程序，使用同样简单而强大 的模型作为 Spring Boot RESTful 微服务，并既能够在本机或者像 Pivotal Cloud Foundry，Kubernetes 这样的平台上运行。有了 Spring Cloud Data Flow，开发人员可以继续使用熟悉的 XD 工具 ， 如 Java-DSL，xd-shell, admin-ui, flo 和 rest-api 。与此同时 ， 全新再设计的体系结构提取所有的样板配置 ， 用可靠的方式来策划数据流处理和数据批处理流程 。 Spring Cloud Data Flow 管理器本身就是一个 Spring Boot 应用程序 。
CI/CD（持续集成 / 持续交付）
现代化应用比较推荐的交付链是从源代码推送到源码仓库，打包之后就是通常所讲的构建过程，构建之后会推送到二进制仓库以保存不同版本的源代码包，这些源代码包通过交付链推送到不同环境中，可能是开发环境、测试环境或者生态环境，所有这些交付链上的环节如果都通过手工方式去做，当微服务数量非常庞大时，工作量就会非常大。CI/CD 更多的是通过自动化的方式，或者是自动化的交付工具链，帮助开发和运维人员更快速地从源代码部署到相应云平台。
随着越来越多企业和开发者持续演进其微服务架构，刘凡认为，微服务未来将向 FaaS/Serverless 方向发展，基于事件驱动的微服务的使用会越来越广泛，因为平台会不断重塑，重塑之后可以帮助开发人员减少对于平台的依赖性，更关注业务本身，微服务的粒度就会随之变小，甚至成为一个函数，进而帮助开发者完成一些关键计算和逻辑问题。Pivotal 将在帮助企业进行数字化转型的过程中更多做一些成熟、稳定的解决方案，持续推行基于云原生的方法论，基于客户需求不断进行方法论和最佳实践的演进。
嘉宾介绍：
刘凡，Pivotal 云平台资深架构师，主要负责架构和客户解决方案应用，过往曾在不同的企业做过分布式系统，包括 J2EE 系统和企业级应用开发工作。
刘凡长期从事软件研发和技术创新工作，曾先后就职于石化盈科、Adobe 中国研发中心、IBM 等大型国内外 IT 企业，从事软件产品研发，系统架构设计，研发管理等工作。在十多年的软件行业从业经历中，积累了丰富的分布式系统架构设计、自动化平台运维和系统稳定性调优等相关经验。近期主要专注于微服务云原生应用的开发和设计，支持多个知名客户企业进行数字化转型，对敏捷开发和传统巨石应用拆分以及往云上迁移拥有丰富的实战经验。
点击“了解更多”阅读更多优质内容
| 留言与评论（共有 0 条评论） |
