微服务架构的产生与演变

伴随互联网信息化不断发展，各企业对信息化建设的重视程度提升，不断引进、投入新的技术与工具，众多技术之中微服务是分布式架构中的“后起之秀”，其以细粒度、敏捷性、模块化等特征迅速“走红”于企业信息化领域。随着微服务的落地应用，其“弊端”也对应暴露出来，在某些大型场景下，服务的独立部署增加了分布式部署的难度、细粒度服务不断增多难以维护、服务之间相互依赖测试问题更加繁琐。对此微服务架构进行了场景、业务模式上的圈定与优化，今天就来探讨下关于微服务架构的产生与演变。

认识微服务架构

起初微服务架构的出现，是将应用系统的子模块单独划分为一个个细小粒度的服务，强调服务之间相互协调，灵活扩展，过程中与业务能力相匹配，满足业务快速创新需求。随着云上模式的兴起，微服务逐渐转变成云中部署的应用和服务的新技术，在中台战略中作为主要技术支撑前台。

1 微服务构架定义

MSA微服务架构是一种架构模式，不需要像普通服务那样成为一种独立的功能或独立的资源，主要用于围绕企业业务组件创建应用功能，每个应用都可以独立开发、管理、扩展，满足不同用户在不同阶段的业务需求。

对于微服务架构而言，架构中每一个服务均能够独立运行，服务之间采用轻量级的通信协议进行相互沟通（典型为RestFul），每一个单一的服务体均用于支持某一类业务，并且能够独立部署与运行服务器中，服务之间并不相互依赖，支持多种语言、脚本进行开发，很大程度上降低了开发者的门槛。

2 微服务架构产生

微服务技术架构的出现并不是毫无来源突然出现，而是经过企业不同的架构模式逐渐演变过来的，在信息技术领域不断发展的过程中，企业信息化架构的演变过程由原有的单体化模式转型为服务化模式，从单体架构——面向服务架构——微服务架构。

• 单体应用架构

在信息化建设的初期广泛应用的架构为单体架构。单体架构主要整合项目的前端与后端，并且运营在统一的服务环境中，应用模块之间的调用过程只需要相互引用即可，项目架构简单，前期开发成本低廉。但随着系统内部功能量级不断增大，单体架构弊端逐渐暴露出来。开发困难：对于系统业务庞杂项目，熟悉、支撑业务越来越耗时，开发难度高；部署困难：牵一发而动全身，调整一个功能，整体功能全部瘫痪；迭代性差：伴随企业业务不断创新单体架构已经很难支撑业务创新。

• SOA服务架构

基于单体架构不能适合复杂业务的弊端，为适应、支持企业不断发展的业务模式，服务架构出现，代表为SOA服务架构，基于SOA服务理念进行功能的抽取，将原有单体架构下的应用服务化，使用接口通信，降低模块之间的耦合度；针对某个系统进行扩展，集成与开发更加容易，在扩展新功能时仅需要调用其对应模块的服务即可；架构也可以支撑灵活的分布式部署，满足性能及响应的需求。不过这种架构在一些前端的互联网电商或零售业务上，支撑其业务快速创新与设计响应上略显逊色。

• MSA微服务架构

基于上述的问题及技术的发展，微服务架构出现，微服务架构中最核心的内涵就是组件，即“系统”是由不同的服务组件构成，并且每个/类组件均能进行独立开发、独立测试、独立部署、独立扩展，开发语言更加灵活，不要求基于语言的统一，每个粒度的服务均可依据实际业务模式及技术人员的水平、领域选择自身更为适应的框架、语言。从运维角度而言，单独的微服务可以专业的团队人员进行维护，而不需要运维人员全面掌握整体的业务逻辑，降低了运维人员工作量与工作压力。

3 微服务架构特性

应用组件化：对服务进行组件化分解，每一个服务全部独立开发、测试、部署，避免修改一个服务而对整个系统进行重新部署，耦合度低，灵活性高，不会出现牵一发而动全身的现象。

技术多样性：微服务架构不同于单体架构采用统一的技术或平台来解决项目需求，也不同于服务架构采用统一的平台体系来解决项目需求，而是根据不同的业务特性选择适合的解决方案，存在技术的多样性。

前后端分离：对于微服务类项目，通常采用前后端分离模式，前端业务的实现与后端技术的支撑为两拨团队共同完成，每个团队可以更好的负责所在的业务领域，边界清晰。

业务响应式：从始至终注重对业务的支撑，以业务能力为核心，从下至上构建整个架构，按照业务的需求划分团队及解决方案，意在实现业务的不断创新与迭代。

微服务架构发展

微服务技术与理念在很多场景得到了应用与验证，被认可的同时也存在一定的争议，因为不是所有的业务场景都适合使用微服务架构技术去解决，正如上文所说，随着技术应用的深入，微服务的定位与界限也逐渐被明确出来，其发展趋势可以概括为大热——冷却——调整。

1 名声大噪

随着互联网技术的发展，许多新技术、名词不断涌现，微服务便是其中之一，微服务架构凭借着松耦合、细粒度、更快的交付时间、提高开发人员的生产效率、前后端分离模式、灵活支撑业务创新、更易调试维护等优势，迅速被各行业及软件厂商关注及应用。因为对于开发人员来说，希望可以提高开发效率与质量，微服务不仅可以提高效率还便于后期的维护；对于企业来说，希望信息化基础设施可以支撑与促进业务的发展创新，在这种背景下很多IT建设项目开始采用微服务架构模式开发。

2 热度消退

随着微服务架构在传统企业的普及应用，其热度逐渐下降，人们对于微服务架构的应用有了更冷静的思考，热度下降一方面是其从概念阶段逐渐落地，不再处于风头阶段。另一方面则是这种治理模式在传统企业应用过程中遇到了严峻的挑战，因为传统企业的信息化建设不同于互联网厂商，传统企业信息化多为由下至上构建，信息孤岛现象严重，与其将这些巨石应用拆分为更细的粒度去维护，不如将现有应用进行统一整合集成，实现统一技术架构上的统一标准，保证可扩展的同时实现统一监管。

3 逐步落地

随着微服务架构热度的下降，一些相关产品或解决方案的厂商也开始意识到在传统企业IT架构中，只是依赖微服务技术理念并不能有效解决企业现有问题，对此微服务技术重新定位优化升级。微服务架构之所以在互联网企业的应用实践中推出兴起，是因为互联网产品功能复杂，业务模块较多，强调创新与快速变化，而传统企业很少甚至不具备这种业务场景，更多为其核心的营销管理、运营管理、生产管理等。对此微服务技术做了对应的调整，主打对企业前端业务的支撑，慢慢在最适合的场景，如：偏向于物流、电商、金融等前端线上交易较多的场景里逐步落地。

微服务架构外延

微服务架构从出现开始，就一直被与各种技术架构进行比较，最常见的为SOA面向服务集成架构，项目打单中总是可以看见不同的厂商将两者放在方案中进行对比，在客户眼里两者是对立的、替代的，事实上两者并不是替代关系，在一定程度上可以相互融合共同合作。除此之外，中台架构战略的提出，让降温后的微服务架构再次走入大家的视线，下面就微服务架构与两者的关系进行分析。

1 微服务与SOA

首先了解一下SOA架构，SOA（Service Oriented Architecture ）为面向服务的架构，它是一个组件模型，将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

对于微服务架构来说，其内部组件各自拥有独立的生命周期，可以实现按需扩展，打破组件之间的技术依赖，开发者可以选择最合适的技术实现需求，一定程度上微服务使技术方案变得更加灵活。但对于复杂的大型项目来说，将企业内部数十种业务拆分成不同的组件、技术来实现就显得不太现实，暂且不计较需要兼顾的技术及语言，对整体项目服务本身的调用、日志流量的监控、安全性等问题都会加大项目的实施难度。

在两者的关系上，说一种架构比另一种架构优秀，未免有些绝对，很多时候应该去考虑技术架构适应的业务场景，对于多种异构系统、大型复杂的综合集成、数据治理分析等项目应该使用SOA架构搭建统一平台、建立统一集成标准，对于电商类、移动应用类、小型程序类等项目需求使用微服务架构更加适合。

2 微服务与中台

同样先来了解下中台战略，中台战略最初被阿里巴巴应用并带起，主要针对于业务种类繁杂，个人/企业会员数量庞大不同种类业务相互交叉依赖，需要根据需求变化快速响应调整的O2O线上线下协同的电商场景。中台战略的提出与微服务架构的提出场景类似，也受到各方的青睐，从电商场景推广至传统企业场景，经过试水之后重新定位在电商、零售等特定领域。

的确，大中台战略的业务中台能力与微服务架构理念相似，也有人说业务中台所用的能力是对微服务架构的优化升级，其价值都是：组件化、细粒度、天然分布式、重用、自治，是快速调整战略、增强一线业务、创新业务模式的一种支撑。如今阿里、滴滴、京东等互联网厂商都纷纷推出属于自己的中台战略体系架构，事实上其前台能力就是平台的微服务化。

IT正确构建模式

纵观微服务架构的产生、大热、冷却、演变的整体过程，不难发现企业想依赖某种单一的技术手段或单一的应用系统很难支撑业务发展需求。面对不断变化的市场环境，不断创新的技术手段，企业更应该做的是打好现有的信息化基础，之后根据业务需求逐步完善信息化建设内容。

1 完善基础设施

这里的基础设施不仅包括IT建设层面，还包括企业的综合实力，例如：人员、业务板块、信息化团队等，从业务到应用到平台到团队的一体化支撑。对微服务架构也好、中台战略也好，不要操之过急，先做好基础支撑。具体为公司具备基础支撑、生产管理、运营管理、经营决策的信息化系统，之后保证系统之间的数据统一、异构整合、流程串联；其次为公司业务发展到一定的规模，需求变化频繁，对于中台或微服务技术存在真实诉求，且公司具备一定实力（技术能力、数量）的研发团队，之后再进行构建。

2 企业架构规划

上述基础设施的完善离不开企业架构的规划，本文开篇提到传统企业由下至上的信息化构建模式已经不能改变或逆转，但这些不能成为阻碍企业架构规划的理由，企业需要站在整体层面，对IT架构与业务架构进行统一规划，两者相互支撑，通过IT架构建设真正的将业务战略实现落地。分析当前业务模式需要构建哪些技术或平台，从长远角度来看企业未来的发展模式需要如何支撑，在建设微服务架构或中台架构体系前需要解决的问题，最佳构建的时间节点等，在解决历史遗留问题的同时，为未来信息化建设做考虑，真正实施IT支撑业务发展。

3 中台战略支撑

无论是微服务架构本身还是应用于中台架构中的微服务技术，都具备一定的优势，只不过这种优势被限制于特殊的业务场景，以中台战略为例，中台的技术理念是可以被企业借鉴使用的。传统企业可以基于中台战略模式去变形，使其更针对自身的业务模式，常见的为应用中台、集成中台、数据中台，以数据中台作为其它中台构建的支撑，提供数据治理、决策分析、智能决策能力；以集成中台作为整合资源的重要手段，提供系统联动、业务协同能力；以应用中台作为业务中台的前期探索，融合数据中台与集成中台的能力，不断支撑业务迭代升级。

4 平台构建中台

看到这里很多人会有疑问，构建中台架构最终还是要涉及微服务架构或其它新兴技术，在企业不具备完善基础设施的情况下是否可以顺利建成，事实上，这些问题可以基于SOA理念下集成中间件平台产品去实现，即基于平台构建中台，数据中台使用数据总线、主数据治理平台、数据分析平台、数据填报平台组合搭建；集成中台基于企业服务总线、数据总线提供的能力搭建；应用中台通过统一身份管理平台、门户平台（PC、移动）做为业务处理与展现入口，流程平台与开发平台用于开发基于微服务的单体应用。这种模式既符合企业信息化发展阶段，又可以为后续新技术融入奠定基础。

任何时候信息化的建设都要根据企业业务模式的不断演变与发展，在明确企业战略目标的同时制定能够支撑战略落地的架构体系，结合专业的平台产品共同筑建企业的信息化平台，真实的将企业的业务与IT建设相结合、以架构支撑落地、服务于整个企业IT战略，推动企业数字化转型以数据驱动战略、最终保障企业战略达成、扩展市场份额、高速稳健发展。