刘凡|如何从Java 开发者转型微服务？一位 Java 开发者的转型思考简单来说

简单来说，微服务是将大型单体应用程序和服务拆分为数个甚至数十个微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。然而，这个过程涉及很多问题需要解决，比如拆分原则、容量规划、组件选择、服务治理甚至人员配比等。本文， 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 写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征：

刘凡|如何 从Java 开发者转型微服务？一位 Java 开发者的转型思考

刘凡|如何从Java 开发者转型微服务？一位 Java 开发者的转型思考