行业信息化应用架构演进与发展解析

郑金辉

（中国电信系统集成公司，北京 100035）

0 引言

应用架构描述了设计和构建应用的模式与技术，也是业务需求与具体技术之间的连接桥梁。应用架构有两层含义：一是企业级应用架构，也就是EA的概念。企业层面的应用架构起到了承上启下的作用，向上承接了企业战略发展方向和业务模式，向下规划和指导企业各个IT系统的定位和功能，更关注企业的应用架构蓝图、架构标准/原则、系统的边界和定义、系统间的关联关系等方面的内容。二是单系统的实现逻辑和组成架构，从前端展示到业务处理逻辑，再到后台数据，整体设计需要遵循企业总体应用架构原则。

1 从单体应用到微服务，应用架构逐渐走向成熟

应该明确，应用架构一定是为业务服务的，是围绕业务需求展开的。应用架构应从业务需求出发，是一个不断演进和完善的过程，是需求在推动技术落地，而不是为了技术而改变架构。先进的技术必然会引起架构复杂度的上升，而这种成本和代价不是谁都能承受得起的。应用架构演进，是一个从小到大的渐进明细的过程，也是一个从孤立走向集中，又从集中重新到分散的过程。

（1）垂直应用架构。其实可以简单理解成单体应用架构，最初业务流量小，对资源的需求也小，所有的应用打包在一起部署在一台物理机上，可以运行得很流畅。后来考虑到系统安全，做了主备配置，实现了部分高可用。再后来流量上来了，先考虑把数据部分拆走，有了App和DB分开部署的模式。再后来人们用负载均衡设备或者Nginx等组件实现应用服务的负载均衡。这样的架构陪我们走过了很多年，直到现在还能在很多客户那里见到。不是说单体应用架构一定不好，只要能满足业务的需求，越简单的东西越有实际价值。

（2）分布式架构。随着业务的发展和组织的壮大，在康威定律的加持下，组织的复杂性开始影响系统的复杂性，单体应用已经不能满足生产的需要，不得不考虑把一部分应用功能分开部署。系统各模块分开部署以后必然带来协同工作的问题，于是有了RPC和消息中间件等技术手段来解决这个问题。其实简单说，RPC侧重于功能调用，多为同步方式，MQ主要是面向性能的，多为异步。RPC和MQ看似不是一个层面的东西，但是却能解决很多共性的问题，比如分布式、解耦等，区别只是实现方式和效果的不同。

（3）SOA（面向服务架构）。SOA跟分布式紧密相关，SOA是一种直到现在依然适用的架构理念，SOA不是技术，却在指导技术如何落地。SOA的特点就是服务中心理念，随着业务发展，服务数量越来越多，服务生命周期管控和运行态的治理成为瓶颈，此时用于提升服务质量的SOA成为架构治理的关键。

（4）微服务架构。系统的复杂度发展到了一定程度，就必然会做进一步拆分。微服务的目的就是进行有效应用拆分，实现敏捷开发和部署。拆分以后的服务可以独立部署、运行、升级。不仅如此，不同微服务之间在结构上也实现了松耦合，但在功能上则表现为一个统一的整体[1]。统一的整体表现出来就是统一的风格界面、统一的权限管理、统一的安全策略、统一的上线过程、统一的日志和审计方法、统一的调度方式以及统一的访问入口等。

以上应用架构的演进过程，不是新老交替的过程，而是不同架构模式逐渐适配各自场景的过程。适合自己的才是最好的，假如业务负载始终比较稳定，业务逻辑也比较清晰，那保持单体应用的架构也不是不可以。业务压力如果变化剧烈，新需求层出不穷，恐怕不想改应用架构都不行，盲目追新和故步自封都不可取。

2 应用架构演进的问题与困境

在传统模式下，业务侧的需求管理是是粗放的。业务团队单独考虑自身的业务逻辑，不可避免地进行了大量重复建设，而且这种重复建设往往是基于单体架构的。在这种情况下，重复建设所导致的成本、效率和数据不一致问题一直困扰着行业信息化建设[2]。于是我们开始接受服务化和中台化的理念，试图寻找突破口。

我们尝试用中台理念对业务侧做调整，形成了以中台为核心的业务架构，中台的核心是“重用”，重用是一种通用逻辑，但是只有通用逻辑是解决不了问题的，还需要业务流程的定制，也就是个性化逻辑。这就会出现一个新问题，中台所代表的通用逻辑与前台所代表的个性化逻辑会出现节奏不一致的情况，需要在协同、排期、优先级等问题上做出协调和平衡，存在巨大的沟通成本。

伴随着应用架构的演进和中台的发展，我们做了大量服务化改造，形成了很多新的服务。这在技术上也带来了很多新问题和新风险，比如，调用链开始变长，运维难度变大，排障变得困难，组件使用成本开始上升。尤其是到了PaaS层面，如何管控众多服务，是一个必须面对和考虑的问题。

在业务、应用、数据的数量和复杂度都快速增长的大背景下，解耦是始终需要考虑的根本原则[3]。

业务和应用的架构变革，如果只从架构升级改造本身出发，就会出现“头疼医头脚疼医脚”的情况。从上分析可以看出，症结都指向了一个问题，那就是研发管理。

3 研发管理的数字化推动应用架构持续优化

3.1 从信息化走向数字化

当前阶段，研发管理的主流模式已经实现了信息化，基本告别了小作坊时代，实现了项目协作、应用开发、交付部署等环节的工具化和平台化。项目协作主要解决工单管理和工单流转以及知识沉淀等问题，应用开发主要是通过工具完成各工序工作，交付部署主要是实现成果发布上线和交付运维。

研发信息化基于工具和流程管控的模式，是用工具代替了人工，从本质上说还是以人为核心的。研发信息化向研发数字化转型，自动化工具和平台的使用仍然是基础工作，在此基础上，研发数字化还需要关注全局透明化、协同效率提升和效率可度量，这就需要将工具和平台产出的过程数据尽量沉淀到数据平台，并结合业务场景逐步形成统一的研发数据模型，打造以业务价值为核心的研发体系。

工具和平台的使用实现的是流程管控，解决的是局部效能的问题，尤其是资源调度的效能，但这并不代表交付效能的整体提升，我们要做的是从以工具流程为核心向以业务价值为核心转型，实现从局部效能向全局效能的转型。简单说，应该分成三步走，第一步是局部效能的提升，重点还是大量自动化工具的使用以及过程数据的积累和沉淀；第二步是实现整体高效交付，核心思想是实现业务、产品和研发的目标一致化，通过对研发过程数据管理实现研发过程的整体可控；第三步是实现持续改进，主要是根据可视化的结果，进行可量化的持续改进。这里面关键就是需要将研发过程数据链接到研发的价值链管理上去。

3.2 以技术标准化屏蔽复杂性

传统应用的研发过程需要从物理基础设施开始关注，从设备类型、资源提供方式、中间件选型到技术路线和架构方式都需要逐一落实。随着新技术的使用，通过将技术标准化实现了从资源到服务的转换。虚拟化和云平台屏蔽了资源类型的差异，将差异化的物理资源统一成了标准化的云资源，PaaS和分布式基础环境实现了中间件层的标准化，DevOps实现了开发环境的统一和标准化，智能运维实现了运维监控的整合和标准化，也就是说云原生应用构建了一个新的技术关注平面，我们不用再去关心各种资源的细节和差异性。不断推进技术的标准化建设，推动IT从资源建设向服务提供转型，这也是持续提升研发整体效能的关键手段。

3.3 低代码研发的尝试和探索

有观点说低代码研发是潮流，很多客户也在开始关注，希望通过研发工具和平台已经抽象出来的一些通用代码，以及可视化的操作快速创建所需的功能组件，加快软件研发的进度。这无论对客户还是软件开发商来说都是好事，也是提升效率和效能的重要手段[4]。其实无论低代码还是0代码，都是APaaS的范畴，是应用全生命周期的一个环节，但是代码量的降低，并不意味着工作量的降低，这对业务架构和应用架构的灵活性和敏捷程度提出了更高的要求，所以说架构永远都是第一位的。

从这个角度来说，低代码开发平台应该为开发者尽可能屏蔽底层技术细节、减少不必要的技术复杂度，并支撑其更好地应对业务复杂度，满足灵活通用的业务场景需求，这是一个低代码开发平台者所应该尽到的核心职责。

4 结束语

应用架构随着技术发展和业务复杂度的提升而不断演进，它不一定是新人替旧人，而是需要根据具体的业务场景灵活选择。新架构必然有新的风险和成本，不一定适合；传统架构成熟稳定，不一定不适合。上层应用的核心关注点是敏捷，遵循短周期功能迭代原则；中间平台层的核心关注点是复用，遵循中周期能力迭代原则；底层技术底座的核心关注点是可持续，遵循长周期技术迭代原则。