下载掌阅APP，畅读海量书库
立即打开
什么是架构？架构有哪些特点？架构有哪些分类？一万个读者可能有一万个答案。
本节将从架构的定义出发，介绍几类常见的架构形态及其演变路径，从单体到分布式、从分布式到微服务、从微服务到中台。并不是最新的架构就是最好的，符合企业当下业务形态的架构才是好架构。那么，如何选择符合自己业务的架构呢？让我们从了解每个架构的特点开始。
架构（Architecture）这个词源自建筑行业，以下引用百度百科的描述。
软件架构（Software Architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。
通俗地来讲，技术架构就是对软件系统各个维度进行不同模块化的抽象，通过抽象使原本复杂的工程变得易于理解和分工实现。就像泰勒提出的科学管理，通过标准化的作业流程和分工，原本混沌复杂的软件工程被拆分出前端、后端、质量、运维等多个岗位。以后端为例，根据不同的岗位职责，按照康威定律又被拆分出不同的组织，比如订单组、用户组、交易组等，进而使整体的生产力大大提升。因此，架构的本质是抽象分类，进而指导软件系统的实现。
通常好的架构要能够支持高并发、高可用、高扩展。这些都是架构设计中应该关注的特性。除此之外，好的架构还应该关注如下特性。
·可用性和可靠性。由于软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。可用性和可靠性虽然是两个不同的属性，但本质都是为了提升业务连续性，使企业的业务尽可能不中断。
·高性能。高性能体现了架构在同样的物理配置下的业务支撑能力，更高的吞吐量、更低的响应时间意味着对用户更快速地响应。
·易维护性。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映给现有系统。一个易于维护的系统可以有效降低技术支持的费用。
·可扩展性。市场和用户总是在不断变化的，为了适应业务的高速迭代，尤其是一些2B企业的个性化需求，架构要求能够在最小的改动成本下满足更多的需求。这要求架构可以根据客户群的不同和市场需求的变化进行调整。
·安全性。随着《个人信息保护法》和《数据安全法》的出台，信息安全已经成为架构设计中最重要的因素，安全合规不容小觑。
我们常听到各种关于架构的名词，比如业务架构、功能架构、应用架构、技术架构、物理架构等，很多读者可能分不清，这里我们简单梳理一下这几个架构的区别。
业务架构一般是指业务的关键流程、组织形式、信息流。以电商为例，业务架构包括选品、采购、仓储、物流、供应商、订单等一系列的业务版块。业务架构体现的主要是业务模式和流程，核心是定义业务痛点，厘清功能需求和非功能性需求。
功能架构一般是指产品具备的细分功能。例如，电商系统的功能架构可细分为用户管理、登录注册、商品管理、仓库管理、订单管理、购物车管理、支付管理等核心模块。功能架构图体现的是一个产品的核心功能模块。
应用架构一般是指根据业务场景设计出应用的层次结构，制定好应用间的调用、交互方式，确保它们能够融合在一起并满足业务需要。比如，电商系统的应用架构可能有用户中心、权限中心、登录系统、商品中心、搜索引擎、推荐体系、订单系统、交易系统等。应用架构体现的是用什么样的微服务去支持功能的实现。
技术架构一般是指实现应用架构的关键技术栈，如Spring Cloud、ZooKeeper、RocketMQ、Redis、MySQL、Elasticsearch等中间件，以及各种核心流程的时序图、状态图等信息。
物理架构一般是指从物理视角来看IDC中的物理拓扑关系，如防火墙、Nginx、网络、应用服务器、数据库间的调用和数据流转关系。物理架构关注的是如何通过硬件配置硬件和网络来配合软件系统达到可靠性、高可用性、性能、安全性等方面的要求。
除了以上大家耳熟能详的架构分类，还有很多与架构相关的名词，如下所示。
·框架（Framework）：通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，往往是基于一组类库或工具，在特定领域里根据一定的规则组合而成。
·组件（Component）：一组可以复用的业务功能的集合，包含一些对象及其行为。组件可以直接用作业务系统的组成部分，颗粒度一般小于模块，也是一种功能的聚合形式，比如日志组件、权限组件等。
·模块（Module）：基于业务数据或一组相关功能按照特定维度的逻辑划分，也可以看作各种功能按照某种分类的聚合。例如，电商系统可以从业务上划分为用户模块、商品模块、订单模块、支付模块、物流模块等。模块使一个复杂的软件变得更加容易管理和维护。
·服务（Service）：一组对外提供业务处理能力的功能，服务需要使用明确的接口方式（比如Web Service、RESTful等）。服务描述里应该包括约束和策略（比如参数、返回值、通信协议、数据格式等）。
·平台（Platform）：一般来说，是一个领域或方向上的生态系统，是很多解决方案的集大成者，提供了很多服务、接口、规范、标准、功能、工具等。
在Web应用发展早期，大部分工程都是将所有的服务和功能模块打包到一个单一的应用中，如以War包的形式运行在Tomcat进程中，直接与数据库和文件系统交互。
在业务发展早期，业务功能往往比较单一，为了快速支持业务，一般一台服务器、一个应用、一个数据库，就足够支撑起一个单一的业务功能。比如电商业务，登录、下单、商品、库存都在一个单一的应用中进行管理和维护。单体架构在业务发展早期非常轻便，易于搭建开发环境，易于测试和部署。
随着业务的不断增长，用户的访问越来越多，单一应用对磁盘、CPU、内存、数据库的访问要求也越来越高。一台服务器一个应用的配置开始捉襟见肘，更改任何一个小的功能模块，整个应用都要重新进行编译和部署。同时，当有多个需求并行时，发布效率会非常低下，整体的功能耦合性非常大，一个小功能的变动可能会引起整个应用不可用。多种功能的强耦合迫使单体架构走向分布式架构。
随着业务压力增大，并发访问会成为单体架构的瓶颈，最简单的解决方案就是把单体服务横向扩展为多体架构，即将1台服务器分散扩容为N台，分而治之，也就是从单体架构变为分布式架构。但是，扩容为分布式架构也有一个问题，即如何保证用户的请求均匀分散到这N台服务器？倘若用户的流量仍然集中访问其中的某台服务器，这样的分布式架构在本质上与单体架构没有任何区别。要解决这个问题就必须增加一个新模块——负载均衡，此时的架构变成了如图2-1所示。
图2-1 负载均衡架构图
负载均衡一般分为硬负载和软负载，常见的负载均衡算法有轮询、加权、地址散列、最少链接等。有了负载均衡后，不会因为某一个服务的宕机而导致整体服务不可用，架构的可用性大大加强。除了应用的分布式，根据业务量的大小，数据库也会进行水平或垂直拆分，通过分布式架构赋予整体架构高负载的能力。
分布式架构2.0阶段不仅是在部署上实现分布式，应用的边界也更加清晰，从单一架构的大单一职责，拆分出一些大的应用，逐步形成多种服务之间的分布式调用。还是以电商为例，这里可能会拆分出用户服务、订单服务、商品服务、库存服务四大应用，应用之间通过接口进行交互，调用形式可能是REST或者RPC。
·低耦合：有了功能模块的拆分，使用接口进行通信，降低了对数据库的依赖，模块耦合性降低。
·职责清晰：把应用拆成若干个子应用后，一般也是由不同团队进行维护的，这样一来，不同团队与应用的职责也就更加清晰了。
·部署方便：每个应用的发布互相独立、互不干扰，发布和部署更加灵活方便。
·稳定性更高：不会因为某一个应用或功能模块出现问题导致整体服务不可用，整个系统的稳定性更高。
系统间的依赖和链路增多，会增加接口开发的工作量，同时增大服务之间的维护成本，但整体上利大于弊。
分布式架构实现了应用从单进程到多进程的转变，做了粗粒度的服务拆分，微服务架构是在分布式架构的基础上对应用架构进行更细粒度的拆分。在微服务架构出现以前，SOA也曾风靡一时，本书将SOA和微服务合并到一起来讨论。还是以电商为例，用户服务可能会拆分成用户中心、权限、登录等服务，如图2-2所示。
图2-2 微服务架构图
随着Spring Cloud的普及，微服务架构逐步成为大中型企业的主流架构。我们来看下微服务架构有哪些优点。
·耦合性进一步降低：模块更独立，功能拆分更加细化，使代码间的耦合以及数据库、中间件的耦合进一步降低。
·自治性更强：一个微服务就是一个独立的实体，它可以独立部署、升级，微服务与微服务之间通过REST等标准接口进行通信，微服务只与其上下游有关，各个微服务之间更加独立。
·技术独立：各个微服务之间可以用不同的技术栈，服务端应用可以用Java、Go、Python等多种语言实现，数据库可以是MySQL、MongoDB、HBase等不同的类型。
·高可用：随着微服务增多、链路增长，异常也会被分散，一个微服务异常可以通过线程池隔离，利用熔断等技术避免故障扩散和雪崩，大大增加了整个系统的高可用性。
·在微服务架构成为主流架构的同时，很多缺点也被暴露出来。
·复杂度高：微服务采用RPC或REST等方式进行交互，需要考虑网络抖动、消息丢失、幂等、分布式事务等问题，代码的逻辑处理更加复杂。
·粒度难定义：微服务拆成几个合适？什么样的功能模块需要独立成一个微服务？服务拆分的粒度是不好准确定义的，倘若拆得过粗，不利于服务间解耦；如果拆得过细，则会导致应用爆炸，增加系统的复杂性。
·运维复杂度高：微服务的调用关系最终会形成一个大网，故障的定位和排查依托于更加完善的监控报警系统等配套工具。
·性能变慢：微服务一般有一个很长的调用链路，链路过长导致整体接口的性能变慢，响应时间（Response Time，RT）会变长。
随着阿里巴巴“大中台、小前台”概念的提出，一线大厂纷纷建立自己的中台体系，公认比较成熟有效的是数据中台、业务中台、技术中台。中台的本质是进一步提升应用系统的复用性，当组织规模扩大，更多业务场景纷纷涌现时，各部门之间会形成一个个“系统烟囱”。在“系统烟囱”中，重复冗余的功能不断被造出来。
以阿里巴巴为例，淘宝、天猫两个事业部都需要用户管理、商品管理、订单管理等功能，许多业务功能是重复的，如果两个事业部都重复建设，必然会造成极大的资源浪费。阿里巴巴技术栈全景图如图2-3所示。
架构重要的功能之一就是避免重复开发、提升复用能力。在这种背景下，如何避免重复造轮子，如何利用同样的能力快速支撑相似的业务需求是架构需要考虑的问题，于是中台思想应运而生。
中台架构有哪些优点呢？我总结了以下几点。
·降本增效：中台的关键就是降本增效，通过复用、抽象避免不必要的重复开发，提升开发效率。
·支持业务更加快速迭代：通用的能力域可以快速支持新业务线落地，比如新的业务也需要登录、订单的能力，完全不用从0到1构建一套新的体系，直接用中台的能力即可。
图2-3 阿里巴巴技术栈全景图
·打造数字化运营能力：数据中台使企业的数据化价值有更宏观的体现，通过分析核心数据，能够更加精确地对业务进行调整和优化。
·提升组织能力：中台架构的落地一定伴随着组织的调整，中台会打破“部门孤岛”，加深团队间的合作。
然而，中台在企业中落地很难，经过几年的发展，真正落地中台架构的企业很少。现在又有很多企业在质疑中台，在拆中台。并不是中台架构不好，而是企业要根据自己的业务特性和当前所处阶段去选择是否要用中台。