架构十五年：改变的是形态，不变的是目的
业务驱动架构形态变化
过去十几年，随着互联网发展以及业务的多样化，系统的架构也在不断发生变化，总体上来说大体经历了从单体应用架构-垂直应用架构-分布式架构-SOA架构-微服务架构的演变，当前各大企业都在朝着数字化转型和云原生方向前进。
业务驱动与基础设施的进化推动架构发展
“架构要解决业务需求的问题，业务需求的变化驱动着架构的进化”。谭待在采访时说道。从互联网的角度出发，结合业务的主要变化，国内软件架构这15年的发展大致可以分为三个阶段。
第一阶段，互联网正式爆发。这一阶段的特点是网页与用户数据的迅速增多，无论是当时流行的搜索引擎、社交网络，还是工业、电商等行业，互联网的爆发带来的数据量是传统的单机和简单的架构模式无法支持的，传统的架构也无法解决相应的业务问题。因此，软件架构就慢慢从原来的单机系统演变成分布式系统以解决新业务形态带来的问题，诸如在架构层面考虑容错、负载均衡等问题。同时需要注意的是，也正是这个时候开启了后来所谓的大数据时代。
第二阶段，移动互联网的兴起。移动互联网兴起之后，互联网业务的形式又随之发生了比较大的变化。PC互联网时代比较典型的一个例子就是搜索引擎，搜索引擎对时效性要求并不是特别高，对用户来说只要能找到所需要的内容即可，不追求实时在线，这个时候架构更多解决的是吞吐量大的问题。移动时代则不同，推荐、个性化服务已经成为更主流的方式，业务的场景也变成了对实时性要求非常高的情况。
这一阶段架构方面主要的变化就是计算从以前的批量计算变成了流式计算，数据处理从离线变成实时，比较典型的例子就是Hadoop到Spark，再到后面Flink的变化。这其中的变化就涵盖了系统架构对用户数据的处理、文档数据的处理、推荐、广告算法等等，这个时期业务对架构的范式要求更高。另外，这一时期硬件等基础设施的大幅提升与大规模的应用，也对架构的演进起到了非常大的推动作用。
第三阶段，云原生时代。也就是当下，企业上云对许多公司来说已经变成一种默认行为。这个时候业务架构就需要基于云原生进行改造，如何基于云组件做适配，如何合理使用云的弹性、计算存储分离等功能也变的至关重要。如果继续使用老的业务架构跑在云上，那无异于“拉着马车跑在高速公路上”。
云原生出现之后还衍生了一个有趣的现象，在云原生到来之前，企业软件架构与互联网软件架构是分离的，现在这两者已经开始慢慢交融在一起。传统的厂商需要进行数字化转型，其面临的业务需要互联网化，要解决高并发、大吞吐等问题，势必要采用互联网架构。互联网公司经过多年的发展壮大，内部运营管理上也会面临传统企业的问题，比如如何解决开发效率，如何解决新老系统并存，如何进行数据打通等等。总的来说，业务场景的需求变化驱动着架构的演进。PC互联网时代、移动互联网时代、云原生时代（数字化转型时代）的业务需求是不同的，也就对不同时期的架构提出了更多的要求。另外软硬件等基础设施的创新和开源价值的体现等也都对架构的演进起到了非常大的助推作用。
1.1单体架构
单体架构是今天绝大多数软件开发者都学习、实践过的一种软件架构，许多介绍微服务的图书和技术资料中也把这种架构风格的应用，称作“巨石系统”（MonolithicAppplication）。
单体架构模型图概述
（1）单体架构在整个软件架构演进的历史进程里，出现的最早、应用范围最广、使用人数最多、统治时间最长的一种架构风格。
（2）但单体这个名称，是在微服务流行之后，“事后追认”所形成的的概念。此前，没有多少人将“单体”看作一种架构。很少有教如何开发单体架构的开发资料。这一方面体现单体架构的简单性，另外一方面体现出在相当长时间里，大家已经习惯了软件架构就是单体的这种样子。
（）单体不一定就不好，一般有问题的是“大型单体系统”，而不是小型单体系统。对于小型系统，单台机器足以支撑起良好的运行系统，不仅易于开发、测试、部署，而且系统中各个功能、模块、方法的调用都是进程内调用，不会发生进程间通信（Inter-ProcessCommunication,IPC）,因此，运行效率也是最高的。
（4）单体系统的不足，必须在软件的性能需求超过了单机、软件人员规模明显超过了“2张披萨”（2PizzaTeam）范畴前提下才有讨论的价值。
（5）单体系统一般也是分层的。分层架构（LayeredArchitecture）是现在所有系统中普遍认可，采用的软件设计方法，无论是单体还是微服务，亦或是其他架构风格，都会对代码进行纵向层次划分。如果常见的：表示层-》业务层-》持久层-》数据库层，像目前很多传统企业都在用的SpringMVC框架、SSH框架、SSM框架等都可以发布到单体服务器进行应用。
单体分层架构图（6）
另外，单体架构也支持按照技术、功能、职责等维度，将软件拆分为各种模块，以便重用和管理代码。单体系统并不意味只有一个整体的程序封装形式，如果需要，它完全可以由多个JAR，WAR，DDL，Assembly或者其他模块格式来构成。即使从横向扩展（ScaleHorizontally）角度衡量，在负载均衡器之后同时部署若干个单体副本系统，以达到分摊流量压力的效果。
单体架构的优缺点
1、优点
单体系统所有代码运行在同一个进程内，所有模块、方法的调用都无须考虑网络分区、对象复制的性能损失。进程内的调用简单、高效。发布、部署简单，方便运维。
2、缺点
（1）任何一部分代码出现缺陷，过度消耗进程空间内的资源，所造成的营销也是全局性的，难以隔离的。项目大而笨重，改动一处都要进行重新打包、发布。
（2）譬如：内存泄露、线程爆炸、阻塞、死循环等问题，不仅仅影响某个一个功能、模块的正常运作，还会影响整个程序。
（）如果出问题的是某些更高层次的公共资源，譬如端口号或者数据库连接池泄露，还将会影响整台机器甚至集群中其他单体副本的正常工作。
（4）由于隔离能力的缺失，单体难以阻断错误传播、不便于动态更新程序。还面临难以技术异构的困难，每个模块的代码通常都需要使用一样的程序语言，乃至一样的框架去开发。
微服务取代单体的最重要原因：单体系统架构风格要求每一个部件、每一处代码都尽量可靠，尽量不出或少出缺陷。然而,当系统规模越来越大时，交付一个可靠的单体系统就变得越来越具有挑战性。软件架构的演进，构建可靠系统的观念“追求尽量不出错”到正视“出错是必然”的转变，才是微服务架构得以挑战并逐步取代单体架构的主要原因。允许程序出错，获得自治与隔离能力，以及可以实现技术异构等目标，是继性能与算力之后，让程序再次选择分布式的理由。SOA就是曾经的探索过的方法之一。新旧世纪之交（20世纪-21世纪）用来对一个大的单体系统拆分为若干个更小的，不运行在同一进程的独立服务，这些服务的拆分方法后来带来了面向服务架构的一段兴盛期。
1.2分布式架构
分布式系统是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上，通过接口进行数据交互。严格意义上来说，它属于是部署层面的架构思想，但是它也属于我们后面所说的微服务。这种做法的好处是，可以提高系统的运算能力。与分布式系统相对应的就是单体应用系统，单体应用系统的思想是allinone思想，就是全部在一起，一个系统的全部服务都集中在一个网络节点上。
单体应用和分布式应用对比图集群
从分布式部署架构上延伸出来的集群概念：所谓集群就是，相同的事情多个人做，比如在上图分布式系统中，商品服务被部署到一台机器上，但是如果在购物节时，请求太多，一台机器根本扛不住，这时我们也增加10台机器，这10台机器都部署商品服务,这样由这10台机器就组成了商品服务集群，集群的初衷就是提高系统的吞吐量，另一个就是提高可用性，比如一台服务器挂了，不至于服务不可用。
缺点
虽然分布式架构能解决一系列问题，但是它经常和后面说的SOA、微服务架构结合使用，分布式架构是从软件部署层面来描述的。它固然也存在很多复杂的问题，如，事物一致性等。
1.SOA架构
SOA全称是:ServiceOrientedArchitecture，中文释义为“面向服务的架构”，它是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。它是一种在计算机环境中设计、开发、部署和管理离散模型的方法。SOA不是一种新鲜事物，它是在企业内部IT系统重复构建以及效率低下的背景下提出的。在SOA模型中，所有的功能都被定义成了独立的服务，所有的服务通过服务总线(ESB)或流程管理器来连接。这种松散耦合的结构使得能够以最小的代价整合已经存在的各种异构系统，当然，由于需要实现对各种异构系统的适配(通常使用ESB来完成不同系统之间的协议转换及数据格式转换)，因此，其本身也会引入更多的复杂性。
实施SOA的关键目标是实现企业IT资产的最大化作用。要实现这一目标，就要在实施SOA的过程中牢记以下特征：可从企业外部访问、随时可用、粗粒度的服务接口分级、松散耦合、可重用的服务、服务接口设计管理、标准化的服务接口、支持各种消息模式、精确定义的服务契约。
SOA架构图服务消费者（ServiceConsumer）可以通过发送消息来调用服务，这些消息由一个服务总线（ServiceBus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引（BusinessRulesEngine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（ServiceManagementInfrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（RegulatoryRequirement），例如SarbanesOxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。
SOA所要解决的核心问题
系统间的集成:我们站在系统的角度来看，首先要解决各个系统间的通信问题，目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范，比如ESB、以及技术规范、服务管理规范;这一步解决的核心问题是。
系统的服务化:我们站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生，目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用;这步要解决的核心问题是。
业务的服务化:我们站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是。
SOA架构的时代特性
SOA软件架构时代，包含了许多概念、思想，在今天的微服务中有能找到对应的身影，譬如：服务之间的松散耦合、注册、发现、治理、隔离、编排等。SOA对这些问题，包括“软件开发”，都指导的更具体，更系统，如下：
更具体：SOA本身属于抽象概念，不是某一种具体的技术1、比**单体架构、烟囱式架构（InformationSiloArchitecture）、微内核架构（MicrokernelArchitecture）、事件驱动架构（Event-DrivenArchitecture）**操作性更强。2、不能简单的认为是一种架构风格，更是一套软件设计的基础平台、有清晰的指导原则：eg：服务的封装性、自治、松耦合、可重用、可组合、无状态等等4、采用SOAP作为远程调用协议，依靠SOAP协议族（WSDL、UDDI和WS-*协议）来完成服务的发布、发现和治理。5、利用ESB企业服务总线（EnterpriseServiceBus，ESB）的消息管道来实现各个子系统之间的交互，令各服务在ESB的调度下无须相互依赖就能相互通信，实现了服务的松耦合，也为后续进一步实现业务流程编排（BusinessProcessManagement，BPM)提供了基础。6、使用服务数据对象（ServiceDataObject，SDO）来访问和表示数据7、使用服务组件架构（ServiceComponentArchitecture，SCA）来定义服务封装的形式和服务运行的容器。
更系统：SOA终极目标希望总结出一套自上而下的软件研发方法论，做到企业只需要跟着SOA的思路，就能一揽子解决掉开发过程中的全部问题。譬如：该如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发/测试/部署新的功能等。SOA还