如果在诸多热门云计算技术中，诸如容器、微服务、DevOps、OpenStack 等，找出一个最火的方向，那么非微服务莫属。尽管话题炙手可热，但对传统行业来说，微服务落地和方法论目前处于起步阶段。
日前，拓扑社（微信：tobshe）联合数人云发布了《微服务2017年报告》。本报告于2017年11月份展开，从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。
希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。
在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。
我们发现传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高，传统架构不堪重负。微服务架构具有明显的好处，尤其是在应对复杂业务系统的多变需求方面。
在本次调研企业中，每个月都要进行业务系统更新的比例占63%，只有不到20%的企业半年以上更新一次系统。
加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化，许多传统行业线上业务出现急速增长。
比如金融行业的移动支付、互联网理财等，汽车制造行业的营销、电商、售后服务等线上业务比例迅速提高。IT团队业务开发、迭代都以每月、甚至每周来计，需要7*24小时响应，这些给系统开发和运维带来极大挑战。
在IT对业务的响应和支撑方面，不同行业所面临的困扰略有不同，但总体差异不明显。
根据调研显示，系统支撑方面排在前四的难题分别为：系统复杂性越来越高（28%），运维管理复杂度高，打造一支全栈运维团队困难（26%），线上访问压力大（19%），设备采购维护成本高（19%）。
在传统单体或SOA架构下，应用如果频繁升级更新，开发团队非常痛苦。企业的业务应用经过多年IT建设，系统非常庞大，要改动其中任何一小部分，都需要重新部署整个应用，敏捷开发和快速交付无从谈起。
传统企业在长期的IT建设过程中，通常大量使用外包团队，这导致采用的技术栈之间差异较大，统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级，并快速响应。
在此时脱颖而出的微服务技术，面对上述困惑几乎浑身优点：独立开发、独立部署、独立发布，去中心化管理，支持高并发高可用，支持丰富技术栈，企业可以根据需要灵活技术选型。
1.微服务客户画像
微服务架构在企业的使用情况可以分为四个层次：初级使用者、轻度使用者、中度使用者、以及重度使用者。
初级使用者基本是传统架构，独立部署需求不突出，技术堆栈不成熟，需要较长的培育和成长期。
轻度使用的企业边缘业务系统开始使用Spring Boot 或Spring Cloud等框架，但组件的使用尚不熟练。
中度使用者为使用Dubbo或Spring cloud时间较长，但还没有做周边配套的工具链。
重度使用者是那些走在微服务架构改造前沿，具备微服务规划和体系，有自己研发实力的企业，通常是以技术见长的大型互联网公司。
2.15% 左右的调研企业引入了SpringCloud、Dubbo等微服务主流开发框架。
此次调研中，6%的企业已经部分引入了Spring Cloud 开发框架，Spring Cloud 也被开发者认为是最好的开发框架。
另外，9%的受访企业采用了 Dubbo 等其他微服务框架，也就是说引入了或考虑引入微服务架构的企业达15%。
此外，还有51%以上的企业在考虑往云原生方向转型。这是由于企业数字化转型背景下，IT要更好适应线上业务趋势的必然要求。加上国家政策层面对云服务的支持，传统企业云化是大势所趋。
3.微服务四大技术优势受青睐
从IT技术发展趋势看，无论硬件、软件、还是基础架构都在朝着轻量化的方向发展。微服务通过化整为零的概念，将复杂的IT部署分解成更小、更独立的微服务。
相对传统的建设方法，传统企业更看重微服务如下四方面的优势：技术选型灵活，更轻松采用新架构和语言（28%）降低系统内部服务冗余，提升开发效率（27%）独立部署（22%）更好的容错机制（20%）
在涉及复杂项目时，和单体架构的对比中，微服务从多个角度显示出了压倒性的优势。
4.制造业开始发力、金融小试牛刀
这里所说制造业，是大制造的概念，包括制造、汽车、大型制造以及航空业等。从调研数据来看，这些行业引入Spring Cloud、Dubbo等微服务开发框架的占比略高于其他行业，超过15%。制造业开始初步尝试微服务架构。
能看出制造业向“智造”转型的影响，今天的制造业结合了物联网、传感器、云计算、大数据等技术，人工智能技术正在工业、汽车驾驶等领域应用。大量新兴业务场景出现，服务变得复杂，产业的弯道超车带来了明显的微服务需求。
其次，需求明显的为金融行业，包括银行、保险、证券等。尤其是一些国有银行、股份制银行以及城商行等大行都走在架构改造的前列。
在自己的创新业务，如手机银行、微信银行、互联网理财等业务上试水微服务架构。在核心业务系统方面，则相当谨慎。一方面是由于监管和政策的原因，另一方面，银行开发体系庞大，IT架构变革将是一件非常复杂的事情。
5.微服务推进障碍
微服务不是完美架构，会带来系统的各种复杂度，以及运维要求更高等诸多难点
微服务并不是一项横空出世的技术，事实上MicroService的概念已经诞生多年。除了组件和技术不成熟，企业业务模式不急迫的因素外，微服务本身也有自己的劣势。
本次调研，有近一半的企业会谈到对微服务的顾虑。比如部署以后的复杂度，后期运维管理的不友好等等。对于团队来说，搭建微服务架构上手难，运维效率低，运维成本高。
另外，还可能带来团队之间沟通上的冲突，微服务需要与DevOps同步推进。微服务被分割成一个个独立的业务模块后，服务间通信接口设计非常重要。如何科学地将系统部署到服务器上，保证各个服务高效运行，更是难点。
微服务推进过程中有许多障碍。对微服务自身复杂度的担忧、缺少具备相关经验的专家、难以招募专业人才和使用相关工具是三个最普遍的障碍。其中对微服务复杂度的顾虑，排名前三的是运维要求和成本高，分布式架构的网络延迟、容错等挑战，以及较强的部署依赖性。
在接受调研的企业中，2017年在生产环境中采用Docker的比例为9%，测试环境使用达22%。而且规模越大的企业，尤其是服务器规模在500台以上的，是Docker容器的主要采用者。
另外，正在考虑评估中的占到被调研企业的一半以上。企业的关注度急剧升高，Docker使用正在快速普及。
容器和微服务相辅相成，两大技术成熟的时间点非常契合。容器技术的成熟为微服务提供了得天独厚的客观条件。轻量化的容器是微服务的最佳运行环境，微服务应用只有在容器环境下才能保障运维效率的提升。
同时，微服务应用架构对外在组件的管理会变得困难，需要用容器平台去管理中间件，才能发挥出更大价值。
1.企业微服务架构改造需要包括周边配套工具链在内的一整套微服务体系
采用微服务架构改造应用系统，不仅仅是选择开发框架本身，还要建设一套完整的体系架构。既要实现应用模块之间的解耦，还要实现统一管理。
微服务化体系，包括开发框架、以及周边配套工具链和组件，比如服务注册、服务发现、API网关、负载均衡、服务治理、配置中心、安全管理、与容器的结合、监控管理等等。一整套的体系建设是微服务真正的难点所在。
落地过程中，受访企业关注的功能包括，API网关（33%）、服务治理（27%）、配置中心（21%）、分布式任务调度（17%）、应用监控与报警（11%）、高并发（7%）等。这些组件可以根据自身的业务特性选择使用。
2.微服务落地方法论：咨询+产品工具+实施
在IT建设中，企业都希望将开发人员的精力放在自身业务系统的开发上，而工具的整合和使用则主要借助外部供应商的力量来做。软件外包商都有自己的发展历程，迅速改变技术架构不太现实。
另外，传统企业都有大量原有IT系统，掉头和转向不可能丢掉历史包袱，全部推翻重新建设。因此，企业一方面有架构之痛，另一方面不得不总是在业务系统快速上线和新架构选择之间平衡。
对于企业来说，最实际的微服务落地路径是，首先纳入微服务咨询，引入外部行业技术专家角色，站在企业架构的总体高度，帮助企业进行微服务体系规划，落地roadmap，然后借助一些产品和工具进行落地实施。
在本次调研中，有的企业鉴于微服务的优势和业务快速变化的需要，会在新项目建设时直接选择微服务架构进行开发，落地方法也不例外。
3、企业践行微服务的三种类型
目前微服务落地的企业可以分为：温柔型的变革者、业务倒逼型的强硬者、观望型的探索者。
具体来说，温柔的变革者从边缘非核心业务探索尝试新兴技术。渐进式实施、创新灵活多变业务是这类型客户微服务切入的关键词。也是大部分传统企业在切入微服务时，选择的路径。
本次参与调研的企业多是如此，在切入微服务时，选择了诸如测试流程、API网关、开发平台升级、测试环境快速部署等非核心业务进行技术验证。
业务倒逼型是那些企业核心业务系统在日常支撑中承受着巨大压力，必须进行架构改造，否则业务运转举步维艰。观望型的探索者，是那些出于业务考量，要看到行业标杆案例，明确收益和价值，以及技术风险和可靠性充分把握的情况下，才会投入资源开始改造。
4.微服务落地需要从上到下推动和密切团队协同
微服务应用的构建依赖组织结构的变化，它按照业务，而不是技术来划分组织，在推进过程中会受到从上到下的压力，因此必须有决策层的支持和推动。同时，需要团队更好的协同，小团队作战，打破团队间的高墙，减少沟通成本。上了微服务的受访企业对搭建一支敏捷团队都感受很迫切。
预计两年内服务网格技术将呈现爆发之势
本次的受访者中，有42%表示听说过 ServiceMesh 这一新兴技术理念，但只有6%的受访者对该技术有过一些研究。
微服务带来的复杂度让企业头疼，尤其是服务间通信，如何保证服务间通信的端到端性能和可靠性，催生了下一代微服务Service mesh。2017年，ServiceMesh 经过技术拥趸、技术社区和媒体的反复布道，迅速被业界了解。
Service Mesh 是服务间通信层，可以提供安全、快速、可靠的服务间通讯。在过去的一年中，Service Mesh 已经成为微服务技术栈里的一个关键组件，被誉为“下一代微服务”。
Conduit、Istio 等Service Mesh技术在市场上已形成激烈的竞争，国内外企业开始纷纷站队。国外，一些有高负载业务流量的公司都在他们的生产应用里加入了Service Mesh。
国内前沿技术公司开始围绕SpringCloud等开发体系，为客户提供成熟的解决方案和工具产品。同时，探索基于 ServiceMesh 的新方案，积极拥抱Istio/Conduit。
当然对于传统企业来说，技术的先进性是为了保障业务需求的快速变化和发展，而不是一味追求新兴。受访企业表示，一方面会主动关注新技术的最新动向，另一方面在考虑落地时，也要关注新技术的可靠性和有例可循，有无业界最佳实践背书。
微服务的核心使命是简化开发，提高IT系统对业务的支撑能力。通过本次调研，我们可以得出如下一些结论：
1.传统行业新兴业务对IT效率的变革需求，业务模式创新重塑要求IT快速响应，是今天微服务炙手可热的主要驱动因素。从目前微服务落地的状态预估有两年左右的培育和成长期。
评估一家企业是否需要上微服务，主要考察这五大关键要素：数据量和业务复杂度，团队规模，应对业务流量变化，是否需要足够的容错容灾，以及功能重复度和差错成本。
2. 实施微服务的理想技术条件包括：进程隔离、数据库表隔离，以及通过公开接口访问。
3. 微服务架构在企业的使用可以分为四个层次：初级使用者、轻度使用者、中度使用者，以及重度使用者。
以技术见长的大型互联网公司首先引领了微服务的风潮，国内制造、金融等大型龙头企业中也有佼佼者开始规划微服务体系，且具备较强的研发实力。大部分企业还处在初步尝试，不成体系，寻找技术和专家力量探讨解决方案的阶段。
4. 微服务和容器共生：容器和微服务相辅相成，天生一对。Docker的成熟，让微服务推广和落地更加可靠、方便。随着Docker和微服务架构组件等相关技术的逐步成熟，微服务架构将逐步落地传统企业。
5. 微服务落地方法论：微服务主要用来解决系统的复杂性问题，企业客户对于如何实施微服务并不清晰，同时有诸多顾虑。受企业客户青睐的落地方法是：微服务咨询+产品工具+实施。
6. 微服务落地策略：微服务正成为许多企业构建应用时的首选。微服务并不缺乏受众，有的企业将微服务用于新应用开发，有的关注将单体应用迁移到微服务架构。
微服务改造循序渐进，快速演化只会适得其反。另外，落地过程中注意开发和运维部门的协同，进行组织内管理创新。
