不了解架构的本质，怎么能打造一个有序的系统呢？

如今的软件系统愈来愈复杂，固然相应地，架构的做用也愈来愈明显。做为开发人员，咱们天天都在和架构打交道，在这个过程当中，对于架构也常常会产生各类各样的问题：

什么是架构？架构都有哪些分类，分别解决什么问题呢？
怎样才是一个好的架构设计？我怎么才能成长为一名优秀的架构师呢？
这些问题涉及咱们对架构的认识，也是学习和运用架构的开始。因此，今天，咱们就来深刻地分析架构的实质，让你可以透彻地理解它。

架构的本质
物理学中有个很著名的“熵增定律”：一个封闭系统，都是从有序到无序，也就是它的熵（即混乱程度）会不断地增长，最终系统会完全变得无序。

这个理论放在软件系统的演化上，也是很是适用的。

一方面，随着业务需求的增长，咱们会往系统里不停地添加业务功能；另外一方面，随着访问量的不断增长，咱们会不断经过技术手段来增强系统非业务功能。若是事先不作良好的设计，随着时间的推动，整个系统野蛮生长，就会逐渐碎片化，愈来愈无序，最终被推倒重来。

不过，天然界中的生物能够经过和外界交互，主动进行新陈代谢，制造“负熵”，也就是下降混乱程度，来保证自身的有序性，继续生存。好比，植物经过光合做用，把光能、二氧化碳和水合成有机物，以此滋养本身，延续生命。对于软件系统，咱们也能够主动地调整系统各个部分的关系，保证系统总体的有序性，来更好地适应不断增加的业务和技术变化。这种系统内部关系的调整就是经过架构实现的，因此，架构的本质就是：

经过合理的内部编排，保证系统高度有序，可以不断扩展，知足业务和技术的变化。
这里包含两层意思，咱们具体展开说下：

首先，架构的出发点是业务和技术在不断复杂化，引发系统混乱，须要经过架构来保证有序。咱们知道架构这个词来源于建筑行业，那为何建筑行业须要“架构”呢？

搭一个草房子很简单，能够直接上手；盖一个 2 层楼房，稍微复杂一些，但在工匠的经验指导下，问题也不大；而盖一座高楼，复杂性就大不同了，咱们须要考虑内部结构、承重、采光、排水、防雷抗震等，这就须要专业员事先作好总体的架构设计，并严格地按照设计来施工。

这里，你能够看到，建筑里的架构不是自然就有的，而是由于建筑愈来愈复杂，咱们须要经过架构来管理这种复杂性，避免建造过程的失控。

软件系统也是如此，从简单的桌面应用发展到如今的大型互联网平台，这个过程当中，系统规模愈来愈大，业务和技术也愈来愈复杂。咱们一样须要经过架构设计，消化复杂性带来的混乱，使系统始终处于一个有序状态，可以应对现有和未来的需求变化。

其次，架构实现从无序到有序，是经过合理的内部编排实现的，基本的手段，就是“分”与“合”，先把系统打散，而后将它们从新组合，造成更合理的关系。

具体地说，“分”就是把系统拆分为各个子系统、模块、组件。拆分的时候，首先要解决每一个部分的定位问题，而后根据定位，划分彼此的边界，最后实现合理的拆分，咱们比较熟悉的微服务架构，就是一种典型的拆分作法。

“合”就是基于业务流程和技术手段，把各个组件有机整合在一块儿。好比说在微服务架构中，拆分为具体微服务后，咱们须要对这些服务进行归类和分层，有些属于底层基础服务，有些属于上层聚合服务，还要尽量地实现服务的平台化，好比咱们最近说的中台，这些都是合的思想体现。

这个分与合的过程将系统的复杂性分解为两个层次：

首先，各个子系统承担独立的职责，内部包含了自身的复杂性。子系统的复杂性对外部是透明的，外部不用关心。
其次，子系统经过封装后，简化为职责明确的一个点，所以，咱们只须要在合的过程当中，解决各个点之间的依赖关系，这样就能够定义出系统总体。
举个例子，咱们都知道 GoF 的 23 个设计模式，在 Builder 模式中，它的主逻辑只须要给出各个部件的组装关系便可，它不关心建立某个具体部件的内部逻辑，这个能够交给工厂模式去实现。这里，Builder 模式负责粗粒度的组装逻辑，它承担的是合的部分；工厂模式负责细粒度的构造逻辑，承担的是分的部分，你们各自管理本身的复杂性。

经过合理的“分”与“合”，系统不是回到了原点，而是把原先铁板一块的系统变成一个富有弹性的结构化系统。这样，系统的复杂性有效地分解了，系统的有序度大幅度地提高了。

固然，系统的复杂性是多方面的，有技术上和业务上的，架构也是一个体系，会有多种架构一块儿来应对这些复杂性挑战。那么接下来，咱们就来具体看下。

架构的分类
按照不一样的角度，架构能够有不少分类，但通常来讲，主要分为业务架构、应用架构和技术架构。那么，这些架构分别为谁服务，解决什么问题，相互之间是什么关系呢？

回答这些问题前，咱们先来看下系统的落地过程。

系统首先由人来开发，而后由机器来运行，人和机器共同参与一个系统的落地。

对于负责开发的人来讲，比较头疼的是，业务太复杂，脑子想不清楚，即便当前勉强把业务逻辑转化为代码，系统后续的维护也是问题。所以，开发人员的要求是系统概念清晰，业务逻辑容易理解，能够直观地进行代码开发。

对于负责运行的机器来讲，比较头疼的是，外部请求并发量太大，致使机器扛不住，有的时候，硬件还会出问题。所以，它的要求是系统可以水平扩展，支持硬件容错，保证系统的高性能和高可用。

这里，开发的痛点主要由业务架构和应用架构来解决，机器的痛点主要由技术架构来解决。

为何这么说呢？咱们看下，这些架构具体都是作什么用的。

简单来讲，业务架构就是讲清楚核心业务的处理过程，定义各个业务模块的相互关系，它从概念层面帮助咱们理解系统面临哪些问题以及如何处理；而应用架构就是讲清楚系统内部是怎么组织的，有哪些应用，相互间是怎么调用的，它从逻辑层面帮助咱们理解系统内部是如何分工与协做的。

技术架构就是讲清楚系统由哪些硬件、操做系统和中间件组成，它们是如何和咱们开发的应用一块儿配合，应对各类异常状况，保持系统的稳定可用。因此，技术架构从物理层面帮助咱们理解系统是如何构造的，以及如何解决稳定性的问题。

这里你能够看到，业务架构、应用架构和技术架构，分别从概念、逻辑和物理层面定义一个系统。业务架构给出了业务模块的划分和依赖关系，这也大体决定了应用系统如何分工和协做，固然这不须要严格地一一对应，好比一个商品业务，可能对应 3 个应用，一个前台商品展现应用、一个后台商品管理应用，以及一个商品基础服务，但这不影响咱们从逻辑上理解，一个业务场景，有哪些应用参与，而且它们是如何协做的。

而技术架构呢，经过保障应用的稳定运行，最终保证业务不出问题。好比在大促的时候，多个应用可能会受大流量冲击，技术架构就要考虑怎么经过技术手段，保障相关的应用可以处理高并发，从而保证大促顺利进行。

这里，我举个拍电影的例子，来帮助你更直观地理解这三种架构的关系：业务架构定义了这个电影的故事情节和场景安排；应用架构进一步定义有哪些角色，每一个角色有哪些职责，而且在每一个场景中，这些角色是如何互动的；技术架构最后肯定这些角色由谁来表演，物理场景上是怎么布置的，以此保证整个拍摄可以顺利完成。

最后，我想强调一下：系统是人的系统，架构首先是为人服务的。所以，业务概念清晰、应用分工合理、人好理解是第一位的。而后，咱们再考虑技术选型的问题，保证系统非功能性目标的实现。因此作架构设计时，通常是先考虑业务架构，再应用架构，最后是技术架构。

什么是好的架构？
从上面的内容，咱们不难看出，一个好的架构必须知足两方面挑战：业务复杂性和技术复杂性。

1. 业务复杂性
   系统首先要知足当前的业务需求，在此基础上，还要知足未来的业务需求，所以系统要能不断地扩展变化，包括调整现有功能，以及增长新功能。

并且，系统的功能变化不能影响现有业务，不要一修改，就牵一发动全身，处处出问题。所以，在架构设计上，要作到系统的柔性可扩展，可以根据业务变化作灵活的调整。

此外，市场不等人，上新业务要快，以前花了半年上了个业务，这回再上个相似的新业务，须要短期就能落地。所以，架构设计上，还要作到系统功能的可重用，这样才能经过快速复用，实现业务敏捷和创新。

2. 技术复杂性
   要保证一个业务能正常运行，除了知足业务功能以外，还要保证这个系统稳定可用。

一个复杂系统是由不少部分组成的，如应用程序、服务器、数据库、网络、中间件等，均可能会出问题。那怎么在出问题时，可以快速恢复系统或者让备用系统顶上去呢？

还有流量问题，平时流量不大，少许机器就能够处理，但在大促的时候，大量流量进来，系统是否是可以经过简单地加机器方式就能支持呢？

此外还有低成本的问题，系统可否作到，使用廉价设备而不是高大上的 IOE 设备，使用免费的开源组件而不是昂贵的商业套件，使用虚拟化技术而不是物理机，而且在流量低谷和高峰的不一样时期，让系统可以弹性缩容和扩容呢？

这些都属于技术性的挑战，解决的是系统的非业务功能，也都是架构设计要支持的。

所以，一个好的架构设计既要知足业务的可扩展、可复用；也要知足系统的高可用、高性能和可伸缩，并尽可能采用低成本的方式落地。因此，对架构设计来讲，技术和业务两手都要抓，两手都要硬。

那么，一个优秀的架构师须要具有什么样的能力，才能设计一个好的架构呢？

什么是好的架构师？
一个优秀的架构师，应具有很强的综合能力，要内外兼修，“下得厨房，上得厅堂”，下面我来经过典型的架构方式，来介绍一名优秀架构师应该具有的能力：

一个驾校教练，一定开车技术好；一个游泳教练，一定游泳水平好，由于这些都是实践性很强的工做。架构师也是同样，TA 一定是一个出色的程序员，写的一手好代码。

在此基础上，架构师要有技术的广度（多领域知识）和深度（技术前瞻）。对主流公司的系统设计很是了解，知道优劣长短，碰到实际问题，很快就能提供多种方案供评估。

此外，架构师还须要有思惟的高度，具有抽象思惟能力。抽象思惟是架构师最重要的能力，架构师要善于把实物概念化并归类。好比，面对一个大型的 B2C 网站，可以迅速抽象为采购 -> 运营 -> 前台搜索 -> 下单 -> 履单这几大模块，对系统分而治之。

架构师还须要有思惟的深度，可以透过问题看本质。透过问题看本质是由事物的表象到实质，往深层次挖掘。好比，看到一段 Java 代码，知道它在 JVM（Java Virtual Machine，Java 虚拟机）中如何执行；一个跨网络调用，知道数据是如何经过各类介质（好比网卡端口）到达目标位置。透过问题看本质，可使架构师可以敏锐地发现底层的真实状况，以端到端闭环的方式去思考问题，可以识别系统的短板并解决它。

还有很重要的一点，能落地的架构才是好架构，因此架构师还须要具有良好的沟通能力（感性），能确保各方对架构达成共识，愿意采起一致的行动；而良好的平衡取舍能力（理性），能够确保架构在现有资源约束下是最合理的，能让理想最终照进现实。
参考资料

https://www.cnblogs.com/awzh2020/p/12513557.html

https://www.cnblogs.com/awzh2020/p/12513483.html

https://www.cnblogs.com/awzh2020/p/12496324.html

https://www.cnblogs.com/awzh2020/p/12496174.html

https://www.cnblogs.com/awzh2020/p/12489362.html

https://www.cnblogs.com/awzh2020/p/12485546.html

https://www.cnblogs.com/awzh2020/p/12482641.html

https://www.cnblogs.com/awzh2020/p/12513557.html
https://www.cnblogs.com/liudianjia/p/12513320.html
https://www.cnblogs.com/liudianjia/p/12513272.html
https://www.cnblogs.com/liudianjia/p/12495990.html
https://www.cnblogs.com/liudianjia/p/12488902.html
https://www.cnblogs.com/liudianjia/p/12484952.html
https://www.cnblogs.com/liudianjia/p/12479110.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12485190.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12482707.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12492287.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12492412.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12507406.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12513642.html

https://www.cnblogs.com/xiangcunjiaoshi/p/12513716.html