本文是《微服务架构转型的20个关键问题》系列文章的第20个问题。
从单体架构到微服务架构的转型，仍然是当前很多企业（尤其是传统企业）所面临的一大挑战。假设有这么一家企业，业务发展不错，但是它正深受单体系统的制约和困扰，亟待进行微服务架构的转型。那么对于微服务架构转型的一把手(或架构师)来说，他/她需要具备哪些能力，才能顺利推进企业的微服务架构转型呢？
在本文中，波波会根据自己的经验和思考，列出微服务架转型所面临的主要挑战。针对这些挑战，波波会说明架构师需要具备的能力。
挑战1：占用业务带宽、影响业务稳定性，耗时漫长，业务不支持
我们知道，但凡有微服务架构转型需求的企业，在业务上一般都是比较成功的。业务上的成功，对于业务线交付团队来说，也就意味着比较重的交付压力。在业务线忙于交付的情况下，你要来搞架构的升级改造，势必对业务的交付，甚至对业务的稳定性都会造成影响。另外，中大型企业的微服务化改造一般耗时都比较漫长，比方说我所经历过的公司，携程经过了至少3年，拍拍贷经过了2年，这么长的周期对业务来说是很难接受的。所以，大部分业务线的老大，一般都不会直接支持你进行微服务架构改造的。
针对挑战1，架构师首先必须理解业务，同时必须具备一定的沟通协调和影响力。只有理解业务，并且具备一定的沟通协调和影响力，你才能够用业务的语言，去和业务方交流，去影响和争取他们的理解和支持。
注：一般在企业中，业务线的人擅长业务视角，技术线的人擅长技术视角，同时擅长技术和业务视角的人比较少。但是作为架构师，你必须同时具备两种视角，你既要能够透过业务的视角去看业务的问题，也要能够将技术的语言转换成业务的语言，帮助业务方理解技术的问题。这种视角和语言的转换能力，对成功的架构转型非常重要。
挑战2：合理的领域拆分和微服务组织架构
相比于技术，微服务转型更难的是合理的业务领域拆分，这首先也需要架构师理解业务，包括领域的边界和相互之间的数据交互。另外，根据康威法则，组织架构和系统架构必须合理映射(或对齐)。微服务架构不仅仅是技术问题，它同时需要合理的组织架构支持，如果你的组织架构是偏传统的层级和职能型架构，那么很难生长出微服务架构来。所以架构师也需要理解微服务的组织架构（本系列的其它文章会回答”系统架构和组织架构是什么关系？“，“微服务架构需要什么样的组织架构支持？”），在做微服务架构转型的同时，架构师需要联动进行一些组织架构的调整。而要进行组织架构调整，架构师又必须和高级管理层+HR进行沟通协调，这又涉及向上管理、沟通协调和影响力。
挑战3：微服务架构的税
微服务架构不是免费的午餐，它是有成本的，这些成本主要包括人才+硬件资源，另外需要微服务基础服务，这些也称为微服务架构的税收。本质上，微服务架构是通过分而治之的策略来分解单体系统的复杂性，但是它同时也引入了分布式系统管理的复杂性，它需要额外的人才、硬件+软件服务来有效地控制和管理分布式复杂性。
微服务架构转型一般需要引入大量的技术人才，比方说我所经历的公司，携程在4年间研发团队从600人左右涨到超过2K人，拍拍贷在2年间研发团队从不到200人涨到超过800人(机器资源从不到200台物理机涨到超过1K台物理机)。通常，从有限的单体系统拆分出几十甚至上百个微服务，必然需要更多的团队+硬件资源去承接和管理这些微服务。所以，但凡经历过微服务架构转型的公司，大都经历过团队和硬件资源的快速增长，当然同时也伴随着业务的快速扩张。
针对人才和硬件资源的挑战，对于架构师来说，他/她需要有很强的招人+团建建设+管理能力，其中招人很大程度上取决于架构师之前的人脉资源积累。另外，招人+硬件资源都是需要钱的，钱是需要高级管理层授权你才能获得的，所以，架构师必须会向上管理、会讲故事，能够争取到资源（钱）。当然，高级管理层要信任你并给你资源，关键还是你的落地和价值创造能力，这些需要你的履历信誉或者前期工作证明(或者你和高级管理层有特殊关系)。
注意，业界真正实现分布式微服务架构的企业其实并不多(以一二线互联网公司为主)，掌握微服务架构迁移技术的技术人才更是稀少，所以他们要价一般都比较贵，通常是普通工程师的1.5倍甚至2倍以上。如何找到这些人，并且说服管理层投资这些人，都是架构师首要解决的问题。
在技术一块，架构师需要理解微服务原理、技术和架构，具体技术包括分布式中间件、监控治理、测试、CI/CD等，同时也要理解大数据技术。只有掌握这些技术（或者能招到掌握这些技术的人才），他/她才能合理设计和构建支撑微服务架构的技术底座。
挑战4：数据库(状态)的拆分，数据一致性问题
当单体系统被拆解成微服务以后，必然涉及数据库(状态)的拆分，状态一致性问题是分布式系统的最大挑战。在技术上基本上可以这样说，所谓微服务架构转型的游戏，本质上就是和状态一致性作斗争的游戏。因此，架构师必须深入理解分布式系统原理和技术。关于这部分内容，本系列的其它文章会陆续展开讲解。
挑战5：工程师文化建设
微服务不仅是一种架构风格和组织风格，也是一种文化风格，它主张
• 各个团队快速、独立、自治地交付
• 鼓励试错而不是问责文化
• 轻流程、追求技术卓越，通过技术驱动业务创新。
在一个重流程的、官僚和问责文化的环境中，很难诞生出微服务架构。因此，作为微服务架构的操盘手，架构师需要在组织内鼓励和推动工程师文化建设，打造微服务架构的文化环境。
总结
1. 微服务架构转型一把手的能力，技术能力大致占1/3，另外2/3是理解业务、组织、招人、管理、沟通协调和影响力。
2.最重要的能力是资源获取和招聘能力，基本上只要能拿到足够资源，合适的人才到位，你本人又generally know how，那么微服务架构转型这个事情基本上就成功了一大半。
3.在一个企业中，业务模式和管理文化对系统架构的影响是最大的。如果一个企业的管理文化非常强势，和微服务架构风格又格格不入，撼动的成本非常高，那么在真正投入微服务架构转型前，架构师需仔细掂量一下，如果确实搬不动，则需要慎重考虑是否投入。
