阿里首席架构师，是如何选择并落地架构方案的

如何针对当前需求，选择合适的应用架构，如何面向将来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都须要深刻思考的问题。

无架构，不系统，架构是大型系统的关键。从形上看，架构是系统的骨架，支撑和连接各个部分；从神上看，架构是系统的灵魂，深入体现业务本质。

架构可细分为业务架构、应用架构、技术架构，业务架构是战略，应用架构是战术，技术架构是装备。其中应用架构承上启下，一方面承接业务架构的落地，另外一方面影响技术选型。

如何针对当前需求，选择合适的应用架构，如何面向将来，保证架构平滑过渡，这个是软件开发者，特别是架构师，都须要深刻思考的问题。本文基于做者在大型互联网系统的实践和思考，和你们一块儿探讨应用架构的选型。

应用架构本质

应用做为独立可部署的单元，为系统划分了明确的边界，深入影响系统功能组织、代码开发、部署和运维等各方面，应用架构定义系统有哪些应用、以及应用之间如何分工和合做。

分有两种方式，一种是水平分，按照功能处理顺序划分应用，好比把系统分为web前端/中间服务/后台任务，这是面向业务深度的划分。另外一种是垂直分，按照不一样的业务类型划分应用，好比进销存系统能够划分为三个独立的应用，这是面向业务广度的划分。

应用的合反映应用之间如何协做，共同完成复杂的业务case，主要体如今应用之间的通信机制和数据格式，通信机制能够是同步调用/异步消息/共享DB访问等，数据格式能够是文本/XML/JSON/二进制等。

应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分下降了业务复杂度，系统更有序，合增长了技术复杂度，系统更无序。

应用架构的本质是经过系统拆分，平衡业务和技术复杂性，保证系统形散神不散。

系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特色；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

常见的应用架构有多种，下面根据系统拆分方式，以及如何平衡业务与技术的角度进行分析，讨论各自的适用性，给企业应用架构选型提供参考。

单体式应用

一、架构模型

系统只有一个应用，相应地，代码放在一个工程里管理；打包成一个应用；部署在一台机器；在一个DB里存储数据。单体式应用的架构以下图所示：

请点击此处输入图片描述

单体式应用采用分层架构，按照调用顺序，从上到下通常为表示层、业务层、数据访问层、DB层，表示层负责用户体验，业务层负责业务逻辑，数据访问层负责DB层的数据存取。

单体应用在水平方向上，上下层之间职责划分清晰；但垂直方向上缺少清晰的边界，上下层模块之间是多对多的依赖关系，好比业务模块1 （图中BO1）可能调用数据层全部模块DAO 1~3， DAO1也可能被业务层全部模块BO1~3调用。

单体应用经过水平分层，下降了业务复杂性；同时模块之间是进程内部调用，技术实现简单。

但单体应用对系统的切分不完全，只有水平切分，而且是逻辑上，所以适合业务比较单一，但深度上比较复杂的系统，好比TCP/IP网络通信，从应用层/传输层/网络层/链路层，层层推动，相似这样的系统能够方便地增长水平层次去适配。

对于广度上复杂的业务，因为缺少垂直切分，强行把不一样业务绑定在一块儿，整个系统神散形不散，带来一系列问题。好比OTA网站包含机票/酒店/旅游等多个垂直业务板块，每块都比较独立，就不适合放在一块儿开发维护。

二、优缺点

单体式应用的优势和缺点都很鲜明，以下图所示。

请点击此处输入图片描述

单体式应用的优势明显：

• 现有IDE都是集成开发环境，很是适合单体式应用，开发、编译、调试一站式搞定。

• 一个应用包含全部功能，容易测试和部署。

• 运行在一个物理节点，环境单一，运行稳定，故障恢复简单。

单体式应用的缺点也明显：

• 业务边界模糊，模块职责不清晰，当系统逐渐变大，代码依赖复杂，难以维护。

• 全部人同时在一个工程上开发，容易发生代码修改冲突，依赖复杂致使项目协调困难，而且局部修改影响不可知，须要全覆盖测试，须要从新部署，难以支持大团队并行开发。

• 当系统很大时，编译和部署耗时。

• 应用水平扩展难，一方面状态在应用内部管理，没法透明路由；另外一方面，不一样模块对资源需求差别大，当业务量增大时，一视同仁地为全部模块增长机器致使硬件浪费。

做者以前曾在一家大型电商公司工做，当时整个网站是一个单体应用，有数百万行代码，有专门的团队负责代码合并，有专门的团队负责编译脚本开发，有一套复杂的火车模型协调不一样团队，整套流程体系很精密很复杂，但这未尝不是单体应用的无奈和代价。

分布式架构应用

一、架构模型

请点击此处输入图片描述

在分布式应用架构中，应用相互独立，每一个应用代码独立开发，独立部署，应用经过有限的API接口互相关联。API接口属于应用一部分，通常和表示层处于同一层次，二者共享业务逻辑层，API和表示层采用一样的web端技术，通信协议通常使用HTTP，数据格式是JSON，应用集成方式比较简化。

分布式架构首先对系统按照业务进行垂直切分，对广度上复杂的业务实现物理解耦，应用内部仍是水平切分，对深度上复杂的业务实现逻辑解耦。分布式架构也能够解决业务量大的问题，对于某些高并发/大流量系统，把系统切分为不一样应用，针对资源需求特色（好比CPU/IO/存储密集型），经过增强硬件配置知足不一样应用的需求，避免一刀切方式带来的资源浪费。

技术上，API采用标准的HTTP/JSON进行通信，调用双方实现难度都不大，可是API通常是“裸奔”的，在系统层面，调用依赖关系不透明，调用可靠性缺少保障，所以只适用应用之间依赖链路少，调用量不大的系统，即应用之间耦合确实够松的系统。

二、优缺点

分布式架构每一个应用内部高内聚，独立开发、测试和部署，支持开发敏捷；同时应用之间松耦合，业务边界清晰，业务依赖明确，支持大项目并行开发，实现业务敏捷。

在分布式架构中，应用的表示层和API没有物理分离，须要同时知足自身业务需求和关联业务需求，相互影响，好比API接口会随着外部应用的需求常常变化，这会致使整个应用从新部署。

运行时，API以HTTP/REST方式经过网络对外提供接口，其通讯可靠性和数据的封装性相对于进程内调用比较差，若是没有一些可靠的技术机制，如路由保障/失败重试/监控等， 裸奔的API方式将严重影响系统总体可用性。

SOA架构

一、架构模型

请点击此处输入图片描述

广义上，SOA也是分布式应用架构一种，但内涵不一样。

这里有两种类型的“应用”，应用1~N是前端应用，面向用户，服务1~N是service，只提供业务逻辑和数据。这些应用都是独立部署，前端应用再也不经过API直接关联，而是经过后端服务共享业务逻辑。

此外相对于“裸奔”的API，SOA架构提供配套的服务治理，包括服务注册、服务路由、服务受权、服务降级、服务监控等等。这些功能经过专门的中间件支持，有中心化和去中心化两种方式，具体技术实现机制和适用场景，网上有不少专门介绍，这里就不展开了。

SOA架构在分布式架构垂直切分的基础上，进一步把原来单体应用的业务逻辑层独立成service，作到物理上的完全分离。

每一个service专一于特定职责，实现系统核心业务逻辑，service之间经过互相调用，能够完成复杂业务逻辑，解决业务深度上的问题；同时service面向众多的应用，以共享的方式支持逻辑复用。因此，SOA架构既体现业务的分，又体现业务的合，更多地从业务总体上考虑系统拆分。

相比分布式应用架构，基于SOA的系统有大量的service应用，整个系统基于服务调用，因此对服务依赖的透明性和服务调用的可靠性提出很高要求，须要专门的SOA框架支持，还须要配套的监控体系和自动化的运维系统支持，技术复杂性高，SOA架构能够集中体现一个企业的IT技术能力。

二、优缺点

SOA架构优缺点以下图所示：

请点击此处输入图片描述

相比较普通API方式，SOA架构更进一步：

• 每一个service都是浓缩的精华，聚焦某方面核心业务，同时以复用的方式供整个系统共享。

• 服务做为独立的应用，独立部署，接口清晰，很容易作自动化测试和部署。

• 服务是无状态的，很容易作水平扩展；经过容器虚拟化技术，实现故障隔离和资源高效利用，业务量大的时候，加机器便可。

• 基于SOA的系统能够根据服务运行状况，灵活调控服务资源，包括服务上下架、服务升降级等，使系统真正具有可运营的能力。

固然天下没有免费的午饭，SOA也带来了额外复杂性和弊端：

• 系统依赖复杂，给开发/测试/部署带来一系列挑战。

• 端到端的调用链路长，可靠性下降，依赖网络情况、服务框架及具体service的质量。

• 分布式数据一致性和分布式事务支持困难，通常经过最终一致性简化解决。

• 端到端的测试和排障复杂，SOA对运维提出更高要求。

SOA落地方式

在实践中，SOA架构不断深刻发展，具体落地形式也多种多样。

一、面向外部SOA

SOA的前身是web service，web service初衷是企业之间经过Internet进行互联，以下图所示：

请点击此处输入图片描述

每一个公司把本身的优点资源经过web service发布，如图中天气服务/机票服务/酒店预订服务来自不一样公司，其余企业能够直接调用服务或整合多个服务，实现企业间资源共享。

二、面向应用SOA

面向应用SOA把原单体应用里的业务逻辑层剥离出来，做为单独的服务对外提供。

举一个电商的例子，这里有两个应用，顾客使用的商品详情页，展现商品的信息、商品库存，商品价格；内部客服人员使用的客服系统，根据顾客来电要求，修改订单，同时也须要获取商品的基本信息、价格信息等。

通过SOA改造后，应用架构以下图所示：

请点击此处输入图片描述

这里的service实现底层数据对于前端页面的透明化，表示层和业务逻辑各自独立维护，同时所有业务逻辑对其余应用开放，新应用能够自由整合来自多个服务的接口，快速支持业务创新。

但每一个service是原系统业务逻辑的封装，接口设计面向原应用的业务case，若是其它应用的需求有差别，则本身建立service访问底层数据。如此致使service职责不够聚焦，相似的接口分散化，同时底层数据表被多方访问，数据模型修改困难，数据一致性难以保障。

最终系统总体依赖复杂，容易造成网状结构，修改时，每每牵一发动全身。

三、微内核SOA

每一个企业都有本身的核心数据，好比对于电商系统来讲，用户/商品/订单/库存/价格都是核心数据，称之为主数据。微内核SOA聚焦各种主数据，封装相关表的全部访问，架构示意以下：

请点击此处输入图片描述

每一个服务独占式地封装对应主数据表的访问，这些服务构成系统的基础服务，一块儿组成系统的微内核，供全部上层应用共享。

微内核服务是原子服务，接口粒度比较细，能够在其上构造聚合服务，为上层应用提供粗粒度服务。能够是信息聚合，好比图中商品聚合服务整合商品的基本信息/库存/价格；也能够是流程聚合，好比下单接口，调用来自多个服务的接口，共同完成复杂的下单操做。

这里服务是分层次的，聚合服务是上层，基础服务是底层，依赖规则以下：

• 上层服务能够调用同层服务和基础服务

• 基础服务是原子服务，不可相互调用

• 前端应用可调用聚合服务和跨层调用基础服务

微内核的微表示服务数量有限，接口粒度细；内核表示这些基础服务处于调用底层，负责核心数据和业务，这和操做系统的内核概念上相似，主数据至关于核心的硬件，如cpu/内存/外存等，微内核的各个基础服务分别负责这些核心资源的管理，屏蔽底层的复杂性，对上层应用提供统一入口和透明化访问。

最近微服务很火，其特征是职责单1、接口粒度细、轻量级通信协议等，微内核SOA架构有微服务的形，同时有业务内核的神，是架构形散神不散思想的很好体现，这个在淘宝、京东、一号店等大型电商系统都已有丰富实践。

四、方式比较

面向企业外部SOA，业务场景有特殊性，不深刻分析，这里主要比较面向应用SOA和微内核SOA的区别，一个大型B2C电商系统，应用和主数据是多对多依赖关系，以下图所示：

请点击此处输入图片描述

面向应用的服务从特定应用出发，整合应用对相关数据的访问需求；从特定主数据出发，收敛各个业务对数据的访问需求。

在面向应用的服务设计下，数据表的访问入口是发散的，来自多个应用，这带来一系列弊端：

1）数据模型碎片化

每一个应用都会基于本身的需求，往表里加字段，不少电商的商品表/订单表有多达200个字段，都是野蛮增加，缺乏控制的结果。

2）数据模型修改困难

相似的访问需求散布在多个服务，缺少整合，同时表schema修改会影响不少服务和应用。

3）链接资源利用率低

多个服务直连数据库，而且每一个服务会尽量多地配置链接数，在应用数量多，业务并发量大的状况下，每每致使数据库链接数不够。

微内核SOA经过收敛对主数据的访问，保证数据模型一致性、优化接口和有效利用数据库链接资源。同时经过服务分层，简化系统依赖关系。更为重要的是，微内核服务保证了业务模型的一致性，好比电商系统的商品体系，包含单品/系列商品/组合商品/搭售商品/虚拟商品等一系列复杂概念，这些复杂逻辑在基础商品服务里处理，对上层业务透明一致。

若是业务模式简单，应用数量少，特定主数据的访问绝大多数（好比说80%）来自某个应用，则服务设计以应用为中心是能够的，不利影响比较小。

对于大型互联网系统，业务广度和深度都复杂，但不管多复杂的系统，主数据类型都是有限的，能够经过聚焦有限的基础业务，以此支持无限的应用业务，结果是底层业务模型稳定，上层业务能够灵活扩展。

面向应用的服务设计是SOA初级阶段，从具体业务着手，自底向上，难度小；微内核服务设计是SOA高级阶段，从全局着手，对业务和数据模型高度抽象，自顶向下，难度大。

值得注意的是，在提供基础服务同时，每一个应用也能够建立本身须要的服务（但主数据的访问必须经过基础服务），因此微内核的服务和面向应用的服务能够有机结合在一块儿，当业务应用变得不少，而且不断增加，能够考虑逐步往基础服务过渡，整合特定主数据有关的业务逻辑。

顺便提一下，应用架构会影响组织架构，若是采用面向应用的服务设计，具体service通常由相关应用的团队负责；若是是微内核的服务设计，通常由单独的共享服务部门负责全部基础服务开发，和各个业务研发部门并列，保证设计的中立性和需求响应的及时性。

应用架构的进化

软件是人类活动的虚拟，业务架构是生产活动的体现，应用架构是具体分工合做关系的体现。

单体应用相似原始氏族时代，氏族内部有简单分工，氏族之间没有联系；分布式架构相似封建社会，每一个家庭自给自足，家庭之间有少许交换关系；SOA架构相似工业时代，企业提供各类成品服务，我为人人，人人为我，相互依赖。微内核的SOA架构相似后工业时代，有些企业聚焦提供水电煤等基础设施服务，其余企业在之上提供生活服务，依赖有层次。

业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构须要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。

企业一开始业务比较简单，好比进销存，此时面向内部用户，提供简单的信息管理系统（MIS），支持数据增删改查便可，单体应用能够知足要求。

随着业务深刻，进销存每块业务都变复杂，同时新增客户关系管理，以更好支持营销，业务的深度和广度都增长，这时须要对系统按照业务拆分，变成一个分布式系统。

更进一步，企业转向互联网+战略，拓展在线交易，线上系统和内部系统业务相似，不必重作一套，此时把内部系统的逻辑作服务化改造，同时供线上线下系统使用，变成一个简单的SOA架构。

紧接着业务模式愈来愈复杂，订单、商品、库存、价格每块玩法都很深刻，好比价格区分会员等级，访问渠道（无线仍是PC），销售方式（团购仍是普通）等，还有大量的价格促销，这些规则很复杂，容易相互冲突，须要把分散到各个业务的价格逻辑进行统一管理，以基础价格服务的方式透明地提供给上层应用，变成一个微内核的SOA架构。

同时无论是企业内部用户，仍是外部顾客所须要的功能，都由不少细分的应用提供支持，须要提供portal，集成相关应用，为不一样用户提供统一视图，顶层变成一个AOA的架构（application orientated architecture）。

随着业务和系统不断进化，最后一个比较完善的大型互联网应用架构以下图所示：

请点击此处输入图片描述

针对上面的技术我特地整理了一下，有不少技术不是靠几句话能讲清楚，因此干脆找朋友录制了一些视频，不少问题其实答案很简单，可是背后的思考和逻辑不简单，要作到知其然还要知其因此然。若是想免费学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java进阶群：650385180，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

1. 具备1-5工做经验的，面对目前流行的技术不知从何下手，须要突破技术瓶颈的能够加群。

2. 在公司待久了，过得很安逸，但跳槽时面试碰壁。须要在短期内进修、跳槽拿高薪的能够加群。

3. 若是没有工做经验，但基础很是扎实，对java工做机制，经常使用设计思想，经常使用java开发框架掌握熟练的能够加群。

最终整个系统化整为零，形神兼备，支持积木式拼装，支持开发敏捷和业务敏捷。

应用架构，须要站在业务和技术中间，在正确的时间点作正确的架构选择，保证系统有序进化。