共计 2257 个字符，预计需要花费 6 分钟才能阅读完成。
什么是架构？
说到架构，这个概念没有很清晰的范畴划分，也没有一个规范的定义，每个人的了解可能都不一样。
架构在百度百科中是这样定义的：架构，又名软件架构，是无关软件整体构造与组件的形象形容，用于领导大型软件系统各个方面的设计。
咱们能够了解为：架构设计的次要目标是为了解决软件系统复杂度带来的问题。
卡内基·梅隆大学的玛丽·肖（Mary Shaw）和戴维·加兰（David Garlan）在文章《软件架构介绍》（An Introduction to Software Architecture）中写到：
“When systems are constructed from many components, the organization of the overall system-the software architecture-presents a new set of design problems.”
译：随着软件系统规模的减少，计算相干的算法和数据结构不再形成次要的设计问题；当零碎由许多局部组成时，整个零碎的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。
软件架构的外围价值，即是控制系统的复杂性，将外围业务逻辑和技术细节的拆散与解耦。
架构师的职责是致力训练本人的思维，用它去了解简单的零碎，通过正当的合成和形象，了解并解析需要，创立有用的模型，确认、细化并扩大模型，治理架构；可能进行零碎合成造成整体架构，可能正确的技术选型，可能制订技术规格阐明并无效推动施行落地。
架构分类
在我的认知体系中，将架构分为业务架构、利用架构、技术架构。当然也据说过数据架构，但大数据畛域超出了我的常识范畴，并不打算作深刻的学习。
咱们来了解一下业务架构、利用架构和技术架构。
在需要初期，业务的需要形容往往比拟含糊。然而大方向上，业务需要是由公司策略决定的。这些策略所产生的一零碎需要，须要业务架构师来进行业务落地，重点在于讲清楚这些需要背地的处理过程，定义各个业务模块的互相关系。
而利用架构、技术架构是为撑持业务架构的落地而存在的。它们的关系环环相扣，下层驱动上层，上层撑持下层。
举一个拍电影的例子。
业务架构定义了这个电影的故事情节和场景安顿；利用架构定义了有哪些角色及其职责，在每个场景中，这些角色是如何互动的；技术架构确定这些角色由谁来表演，物理场景上是怎么安排的，以此保障整个拍摄可能顺利完成。
再举一个电商的例子。
一个商品业务，可能对应 3 个利用，一个前台商品展现利用、一个后盾商品治理利用，以及一个商品根底服务。业务架构定义了一个下单的具体流程；利用架构定义了下单有哪些利用参加以及它们如何合作；技术架构要保障相干的利用可能解决高并发，从而保障大促顺利进行。
业务架构
说到业务啊，那就不得不提产品经理。产品经理的职责就是：通知用户，零碎长什么样子；通知开发，他要实现什么性能。比如说，咱们当初要设计一个电商零碎，用户想在咱们零碎上买货色，一个典型的购物流程，包含商品浏览、退出购物车、下单、领取。
产品经理首先要把每个步骤具体化为页面原型。在原型中，直观的给出各个步骤的输出或输入，以及用户的操作过程，最初再把这些页面串起来，造成一个业务流程。
业务架构师要设计一个购物流程模块，外面蕴含商品查问、增加购物车、下单和领取接口，来别离对应流程里的 4 个业务步骤。
说起来倒是挺简略的，要实现这个购物流程，其实是考验业务架构师的功力的。
首先，业务架构师要把握不同模块的业务和数据模型。这会同时波及商品、购物车、下单和领取四个业务，业务架构师要同时十分分明这四局部的数据模型和业务逻辑。
其次，这个模块要设计的足够灵便。如果一个业务畛域的需要产生了变动，比如说，订单要减少一个新的状态，那么所有波及该订单的模块都要晓得这个变动，并要做出相应的调整。
上面画出了电商零碎的业务架构图，仅供参考：
利用架构
利用架构就是讲清楚零碎外部是怎么组织的，相互间是怎么调用的。咱们熟知的利用架构有：MVC 架构、分层架构、六边形架构。
从单个利用层面讲，利用架构定义了我的项目包的构造，比方分层利用架构，我在这篇文章《基于 start.spring.io，我实现了 Java 脚手架定制》中介绍了实现分层利用架构的过程，它的分层构造如下图所示：
从零碎层面讲，利用架构定义了各个过程间的调用与交互。上面画出了电商零碎的分层架构图，仅供参考：
技术架构
技术架构就是对在业务架构中提出的性能进行技术计划的实现。要害就是讲清楚零碎由哪些硬件、操作系统和中间件组成，它们是如何与咱们开发的利用一起配合，应答各种异常情况，放弃零碎的稳固可用。
这同样要求技术架构师在计算机技术方面有深厚的功力，第一大挑战就是：硬件。
从技术架构的角度，晋升硬件的解决能力个别有两种形式：Scale Up 和 Scale Out。垂直扩大有物理上的瓶颈或老本的问题。受硬件的物理限度，机器的性能是有天花板的。程度扩大如何无效地治理大量的机器，硬件不是 100% 的牢靠，它自身也会出问题。
第二大挑战：软件。
这里的软件，次要说的是各种中间件和零碎级软件。软件在填硬件的各种坑的同时，也给零碎挖了新的坑。
举个例子，Redis 集群的多节点，它解决了单节点解决能力问题，但同时也带来了新的问题，比方 Redis 数据的多正本，它解决了单台服务器故障带来的可用性问题，但同时也带来了数据的一致性问题。
上面画出了电商零碎的技术架构图，仅供参考：
封面
相干文章
兴许你对上面文章也感兴趣。
- 基于 start.spring.io，我实现了 Java 脚手架定制
- Nacos 配置核心落地与实际
