拥抱微服务不需一步到位找对目标比全面重构更重要

Gartner资深研究总监Kevin Matheny建议，拥抱微服务最好不要一步到位，更不要赶流行，「导入微服务要先找对目标，可从面对顾客、需要快速改变的AP入手，一步到位全面重构的成本太高。」

他从两个角度来看微服务架构，微服务的内部架构是容器技术和应用程式的程式码，大多是企业IT开发团队熟悉的领域。「微服务的精神是将大型应用打破成小单位，来实现最小变动，做到每次改变，都刚好是需要的最小调整。」

不过，解构了大型应用程式之后，将内部元件移到应用程式外来运作时，为了控制这些元件之间的存取，「微服务架构的外部环境，需要有一套支持系统和管理系统。」

这些让微服务顺运作的机制，除了用来管理容器的Kubernetes之外，还需要CI/CD自动化机制、用于服务互通管理用的服务网格（Service Mesh）机制、确保微服务运作的监控机制、面对不同前端应用的对外应用闸道器，以及其他后端服务机制等。

「拥抱微服务的代价是，複杂的维运和痛苦的导入过程。」Kevin Matheny指出。后者正是高度e化传统企业的第一个挑战，他认为，若有应用程式需要经常改变，就很适合改用微服务架构，否则不需要。

「若企业的应用程式一个月才需要异动一次，就不需要这样的架构，太浪费了。」例如现有银行核心系统，他就不建议先套用微服务架构。

他解释，微服务架构是一种专供持续变革用的架构，企业可以进行最小幅度的修改，又能同时了解这些修改的影响，作为日后变动的回馈，「通常是面对顾客的系统，例如Web应用，才需要寻求持续不断的变动。」

【微服务设计架构】Gartner提供了一套微服务设计架构，不同的微服务透过容器封装，部署在容器管理平台（如K8s）上，还需搭配CI/CD自动化工具，Service Mesh机制、后端服务、监测机制和对外Gateway。（图片来源／Gartner）

三阶段导入微服务，选对目标是第一步

Kevin Matheny也提供了一套企业三阶段导入微服务的作法。「第一步要选对目标！」先辨识出需要经常改变的应用或服务，而且要从业务利益角度来挑选，同时还要评估企业对于微服务架构的準备度。

第二步则是要强化开发能力。包括要提升IT团队的能力，同时要从产品或应用程式生命週期来思考，并大力拥抱自动化的开发流程和工具，例如CI/CD。

完成了第一、第二步之后，开始从小地方入手，梳理出可从单体式应用中剥离出来的功能API，再从中抽出最小单位的微服务，作为打造微服务的目标和起点。

就算是IT资源较充沛的银行，他认为，最好也先从顾客系统开始拥抱微服务，累积足够的人才和经验后，评估真有需要经常变动的效益，才需要将微服务延伸到核心系统上。

「微服务架构不应该是企业的目标，」Kevin Matheny再三强调这件事，他观察，未来企业IT不会只需管理微服务架构，而是微服务和传统架构并行管理，所以，不要问如何拥抱微服务架构？而要思考，你有什么问题，需要靠微服务才能解决？儘管IT要有大架构和蓝图策略，「先从小服务，开始感受到微服务的好处，远比IT架构大跃进更为可行。」曾在年营收4百亿美元的美国零售巨头Best Buy担任过电商架构总监13年的Kevin Matheny，这是他对有意拥抱微服务的台湾企业，最重要的建议。

 相关报导  企业K8s实战在台湾