前言如何根据当前需求选择合适的应用架构，如何面向未来，保证架构的平滑过渡，这是软件开发者，尤其是架构师需要深入思考的问题。没有架构就没有系统，架构是大系统的关键。从形而上学的角度来看，架构是系统的骨架，支撑和链接各个部分；从精神上讲，架构是系统的灵魂，深刻体现了业务的本质。架构又可以细分为业务架构、应用架构和技术架构。业务架构是战略，应用架构是战术，技术架构是设备。其中，应用架构是承前启后的纽带。一方面承担业务架构的实现，另一方面影响技术选型。如何根据当前需求选择合适的应用架构，以及如何面向未来并保证架构的平稳过渡，是软件开发者尤其是架构师需要深入思考的问题。本文基于作者在大型互联网系统中的实践和思考，与大家共同探讨应用架构的选择。应用架构的本质作为一个独立的可部署单元，应用为系统定义了清晰的边界，深刻影响着系统功能组织、代码开发、部署、运维等。如何划分应用程序和合作之间的工作。划分方式有两种。一种是横向划分，按照功能处理的先后顺序划分应用。比如把系统分成web前端/中间服务/后台任务，就是业务深度的划分。另一种是垂直划分，根据不同的业务类型划分应用。比如进销存系统可以拆分成三个独立的应用，这是对业务广度的划分。应用集成反映了应用如何协作共同完成复杂的业务用例，主要体现在应用之间的通信机制和数据格式上。通信机制可以是同步调用/异步消息/共享DB访问等，数据格式可以是文本/XML/JSON/Binary等。应用的划分偏向业务，反映业务架构，而组合应用偏向技术，影响技术架构。分离降低了业务复杂度，使系统更加有序，而组合则增加了技术复杂度，使系统更加无序。应用架构的本质是通过系统拆分来平衡业务和技术的复杂性，从而保证系统的完整性。系统采用什么样的应用架构受业务复杂度的影响，包括企业发展阶段和业务特点；同时受技术复杂度的影响，包括IT技术发展阶段、内部技术人员水平等。业务复杂（包括业务量大）必然带来技术复杂。应用架构的目标是在解决业务复杂性的同时，避免技术过于复杂，保证业务架构的落地。有许多常见的应用程序架构。下面基于系统拆分的方法以及如何平衡业务和技术进行分析，探讨其适用性，为企业应用架构选择提供参考。单体应用1.架构模型系统只有一个应用。相应地，代码在一个项目中进行管理；打包成一个应用程序；部署在一台机器上；并将数据存储在一个数据库中。单体应用的架构如下图所示：单体应用采用分层架构。按照调用顺序，从上到下一般是表现层、业务层、数据访问层、DB层。表现层负责用户体验，业务层负责业务逻辑，数据访问层负责DB层的数据访问。单体应用是横向的，上下层职责分工明确；但在垂直方向上没有明确的界限，上下模块之间存在多对多的依赖关系。比如业务模块1（图中的BO1）可能会调用数据层的所有模块DAO1~3，DAO1也可能被业务层的所有模块BO1~3调用。单体应用通过水平分层降低业务复杂度；同时，模块在进程内调用，技术实现简单。但是单体应用对系统的划分并不彻底，只是水平划分，而且合乎逻辑，因此适用于业务比较简单，但深入比较复杂的系统，比如TCP/IP网络通信，从应用层/传输层/网络层/链路层，逐层推进，这样的系统很容易提高适配水平。对于广度复杂的业务，由于缺乏垂直切分，不同的业务被强行绑定在一起，整个系统是分散的，从而引发一系列问题。比如OTA网站包含机票/酒店/旅游等多个垂直业务板块，每个板块相对独立，不适合一起开发和维护。2.优缺点单体应用的优缺点非常明显，如下图所示。单体应用的优势很明显：现有的IDE都是集成开发环境，非常适合单体应用，可以一站式开发、编译、调试。一个应用程序包含所有功能，易于测试和部署。运行在一个物理节点上，环境单一，运行稳定，故障恢复简单。单体应用的缺点也很明显：业务边界模糊，模块职责不明确。当系统逐渐变大时，代码依赖复杂，难以维护。大家同时在同一个项目上开发，容易出现代码修改冲突，依赖关系复杂，项目协调困难，部分修改影响未知，需要全覆盖测试，需要重新部署，难度大支持大型团队的并行开发。当系统很大时，编译和部署都比较耗时。很难横向扩展应用程序。一方面，状态是在应用程序内部管理的，不能透明地路由。另一方面，不同的模块在资源需求上有很大差异。当业务量增加时，不加区别地给所有模块加机器，会造成硬件浪费。笔者之前就职于一家大型电商公司。当时，整个网站是一个应用程序，有数百万行代码。有专门的团队负责代码合并，有专门的团队负责编写脚本开发，还有一套复杂的火车模型。协调不同的团队，整个流程体系非常精密和复杂，但这并不是单一应用的无奈和成本。分布式架构应用一、架构模型在分布式应用架构中，应用之间相互独立，各应用代码独立开发，独立部署，应用之间通过有限的API接口相互关联。API接口是应用程序的一部分，一般与表现层处于同一层次。两者共享业务逻辑层。API和表示层使用相同的Web端技术。通信协议一般使用HTTP，数据格式为JSON。应用集成方法相对简化。分布式架构首先按照业务对系统进行垂直拆分，在广度上实现复杂业务的物理解耦，在深度上实现复杂业务的逻辑解耦。分布式架构也可以解决业务量大的问题。对于一些高并发/大流量的系统，将系统分成不同的应用。根据资源需求的特点（如CPU/IO/存储密集型），可以加强硬件配置以满足需求。满足不同应用的需求，避免一刀切造成的资源浪费。技术上，API使用标准的HTTP/JSON进行通信，双方调用起来并不困难。但是，API一般都是“裸奔”的。在系统层面，调用依赖不透明，不保证调用可靠性，因此只适用于应用。相互依赖的环节少，调用量小的系统，即应用之间松耦合的系统。2.优缺点分布式架构每个应用内部内聚度高，独立开发、测试和部署，支持敏捷开发；同时，应用松耦合，业务边界清晰，业务依赖清晰，支持大项目并行开发，实现业务敏捷。在分布式架构中，应用程序的表示层和API在物理上并未分离。他们需要同时满足自身的业务需求和相关的业务需求，并且相互影响。例如，API接口会经常随着外部应用的需求发生变化，从而导致整个应用的重新部署。.API在运行时以HTTP/REST的形式通过网络对外提供接口，其通信可靠性和数据封装性与进程内调用相比相对较差。如果没有可靠的技术机制，比如路由保证/失败重试/监控等，裸奔API方式将严重影响系统的整体可用性。SOA架构1.架构模型从广义上讲，SOA也是一种分布式应用架构，只是内涵不同。有两种类型的“应用程序”。Applications1~N是前端应用，是面向用户的，services1~N是服务，只提供业务逻辑和数据。这些应用独立部署，前端应用不再通过API直接关联，而是通过后端服务共享业务逻辑。此外，与“裸奔”的API相比，SOA架构提供了配套的服务治理，包括服务注册、服务路由、服务授权、服务降级、服务监控等。这些功能由专门的中间件支持，有集中和分散两种方式。具体的技术实现机制和适用场景网上有很多专门的介绍，这里就不展开了。SOA架构在分布式架构垂直切分的基础上，进一步将原来单体应用的业务逻辑层分离成一个服务，从而实现了完全的物理分离。每个服务都专注于特定的职责，实现系统的核心业务逻辑。服务之间通过相互调用完成复杂的业务逻辑，解决业务深度问题。同时，服务面向众多应用，以共享的方式支持逻辑复用。因此，SOA架构不仅体现了业务的划分，更体现了业务的整合，更多的是从业务整体上考虑系统的拆分。与分布式应用架构相比，基于SOA的系统有大量的服务应用，整个系统都是基于服务调用，因此对服务依赖的透明性和服务调用的可靠性有很高的要求，这就需要专门的SOA框架支撑，还需要配套的监控系统和自动化运维系统支撑，技术复杂度高，SOA架构能够集中体现企业的IT技术能力。2.优缺点SOA架构的优缺点如下图所示：SOA架构相对于常见的API方式更进了一步：每一个服务都是一个浓缩的精华，专注于核心业务的某一方面，同时被整个系统以复用的方式共享。服务作为一个独立的应用，独立部署，接口清晰，便于自动化测试和部署。服务无状态，易于横向扩展；通过容器虚拟化技术，实现故障隔离和资源高效利用。业务量大的时候，加机器就够了。基于SOA的系统可以根据服务运行情况灵活控制服务资源，包括服务上架、服务降级等，使系统真正可操作。当然，天下没有免费的午餐，SOA也带来了额外的复杂性和劣势：系统依赖复杂，给开发/测试/部署带来一系列挑战。端到端的呼叫链路长，可靠性降低，取决于网络状况、服务架构和具体服务质量。分布式数据一致性和分布式事务支持的难点一般通过简化最终一致性来解决。端到端的测试和故障排查复杂，SOA对运维提出了更高的要求。SOA的实现方式在实践中，SOA架构不断发展，具体实现形式也多种多样。1、面向外部的SOASOA的前身是webservice。Web服务的初衷是通过互联网将企业互联互通，如下图：各公司通过Web服务发布自己的优势资源，如图天气服务/机票服务/酒店预订服务来自不同的公司和其他公司可以直接调用服务或集成多个服务，实现公司间的资源共享。2、面向应用的SOA面向应用的SOA将业务逻辑层从原来的单一应用中剥离出来，作为一个单独的服务提供。举个电子商务的例子，这里有两个应用。客户使用的商品详情页展示商品信息、商品库存、商品价格；内部客服人员使用的客服系统根据客户来电要求修改订单，还需要获取商品的基本信息、价格信息等。SOA改造后的应用架构如下图所示：这里的服务实现了底层数据对前端页面的透明化，表现层和业务逻辑独立维护，所有业务逻辑对外开放应用程序，并且可以从多个应用程序中自由集成新应用程序。快速支持业务创新的服务接口。但是，每一个服务都是对原有系统业务逻辑的封装，接口设计都是面向原有应用的业务用例的。如果其他应用程序的要求不同，则创建一个服务来访问底层数据。导致服务职责不够集中，类似接口分散。同时，底层数据表被多方访问，数据模型难以修改，数据一致性难以保证。最终系统整体依赖复杂，容易形成网络结构。当它被修改时，它往往会影响到整个身体。3.微内核SOA每个企业都有自己的核心数据。比如对于电子商务系统，用户/商品/订单/库存/价格都是核心数据，称为主数据。微内核SOA关注各类主数据，封装所有相关表的访问。架构如下：每个服务都独占封装了对对应主数据表的访问。这些服务构成了系统的基础服务，共同构成了系统的微内核。所有上层应用共享。微内核服务是原子服务，接口粒度比较细。可以在其上构建聚合服务，为上层应用提供粗粒度的服务。可以是信息聚合，比如图中的商品聚合服务，集成了商品的基本信息/库存/价格；也可以是流程聚合，比如一个订单接口，调用多个服务的接口，共同完成复杂的订单操作。这里的服务是有层次的，聚合服务在上层，基础服务在底层。依赖规则如下：上层服务可以调用同层服务和基础服务。基础服务是原子服务，不能互相调用。前端应用可以调用聚合服务和跨层调用基础服务微内核的微内核说明服务数量有限，接口粒度细；kernel表示这些基础服务处于调用的最底层，负责核心数据和业务，在概念上类似于操作系统的内核，主要数据相当于核心硬件，如cpu/内存/外存等，微内核的各个基础服务负责管理这些核心资源，屏蔽底层的复杂性，为上层应用提供统一入口和透明访问。最近，微服务非常流行，其特点是职责单一、接口粒度细、通信协议轻量级。微内核SOA架构具有微服务的形态，同时具有业务内核的精神。这在淘宝、京东、一号店等大型电商系统中已经得到很好的体现。4、方法对比面向企业外部SOA，业务场景具有特殊性，不深入分析。这里主要比较面向应用的SOA和微内核SOA的区别。在大型B2C电子商务系统中，应用程序和主数据是多对多的依赖关系。如下图所示：面向应用的服务从具体的应用出发，整合应用对相关数据的访问需求；从具体的主数据出发，汇聚各业务的数据接入需求。在面向应用的服务设计下，数据表的访问入口是发散的，来自多个应用，这带来了一系列的弊端：1）数据模型的碎片化每个应用都会根据自己的需要向表中添加字段，很多电商的商品表/订单表多达200个字段，都是野蛮生长和缺乏控制的结果。2）修改数据模型困难。类似的访问需求分布在多个服务中，缺乏集成。同时，表模式的修改会影响很多服务和应用。3）连接资源利用率低。多个服务直接连接到数据库，每个服务会配置尽可能多的连接。在大量应用和大量并发业务的情况下，数据库连接数往往不足。微内核SOA通过汇聚对主数据的访问，保证数据模型的一致性，优化接口，有效利用数据库连接资源。同时，通过服务分层简化系统依赖。更重要的是，微内核服务保证了业务模型的一致性。例如，电子商务系统的产品系统包括单品/系列产品/组合产品/搭售产品/虚拟产品等一系列复杂的概念。这些复杂的逻辑是在基础商品服务中处理的，是透明的，与上层业务保持一致。如果业务模型简单，应用数量少，对特定主数据的访问绝大部分（比如80%）来自某个应用，那么服务设计可以以应用为中心，并且不利影响相对较小。对于大型互联网系统，业务的广度和深度都是复杂的，但再复杂的系统，主数据的类型也是有限的。通过专注于有限的基础服务，可以支持无限的应用服务。结果是基础业务模型是稳定的。上层业务可灵活扩展。面向应用的服务设计是SOA的初级阶段，从具体业务出发，自下而上，难度较小；微内核服务设计是SOA的高级阶段，从全局出发，高度抽象业务和数据模型，自上而下，难度大。值得注意的是，每个应用在提供基础服务的同时，也可以创建自己的服务（但访问主数据必须经过基础服务），这样微内核服务和面向应用的服务就可以有机地结合起来。有许多业务应用程序，并且它们还在不断增长。考虑逐步过渡到基础服务，整合与特定主数据相关的业务逻辑。顺便说一句，应用程序架构会影响组织结构。如果采用面向应用的服务设计，具体服务一般由相关应用团队负责；如果是微内核服务设计，一般会有一个单独的共享服务部门负责所有的基础服务开发。与各业务研发部门并行，确保设计的中立性和需求响应的及时性。应用架构的演进软件是人类活动的虚拟化，业务架构是生产活动的体现，应用架构是具体分工合作的体现。单体应用类似于原始氏族时代，氏族内部有简单的分工，氏族之间没有联系；分布式架构类似于封建社会，每个家庭自给自足，家庭之间存在少量交换关系；SOA架构类似于工业时代，企业提供各种这样的成品服务，我为大家，大家为我，相互依存。微内核的SOA架构类似于后工业时代。一些公司专注于提供水、电、煤等基础设施服务，而另一些公司则在其之上提供生活服务，层层依托。业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适应业务架构，与业务架构一起演进。同时，应用架构依赖于技术架构最终落地。一开始，企业的业务比较简单，如进货、销售、仓储等。此时，它为内部用户提供了一个简单的信息管理系统（MIS），支持数据的增删改查，单一应用即可满足需求。随着业务的深入，开票、销售、入库等各项业务变得更加复杂。同时加入客户关系管理，更好地支持营销。业务的深度和广度不断增加。这时候系统就需要按照业务进行拆分，成为分布式。公式系统。此外，企业纷纷转向“互联网+”战略，扩大网上交易。在线系统类似于内部系统业务。到一个简单的SOA架构中。紧接着，商业模式变得越来越复杂。订单、商品、库存、价格各有深度，如价格区分、会员级别、接入渠道（无线或PC）、销售方式（团购或普通）等，并大量用于价格促销，这些规则非常复杂，很容易相互冲突。需要将分散在各个业务中的价格逻辑统一管理，以基础价格服务的形式透明地提供给上层应用，形成微内核的SOA架构。同时，无论是内部用户还是外部客户需要的功能，都有很多细分的应用支持。需要提供一个入口，整合相关的应用，为不同的用户提供统一的视图。最上层成为AOA架构（面向应用的架构）。随着业务和系统的不断演进，最后一个比较完整的大型互联网应用架构如下图所示：支持敏捷开发和业务。应用架构需要站在业务和技术的中间，在正确的时间点做出正确的架构选择，保证系统的有序演进。老司机介绍作者：王庆友，前一号店首席架构师，曾就职于eBay、腾讯、一号店等公司。精通电子商务业务，擅长复杂系统业务建模和架构分析。同时，他在构建大型分布式系统方面有着丰富的实践，尤其是在大型系统的SOA改造方面有着非常深入的理论和实践。
