架构到底是什么？首先来看一下维基百科对架构的解释:
软件架构：是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对像。
软件架构师：软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程
按照维基百科的解释：软件架构实则是各个组件的互相搭配和组件之间的相互配合,是抽象的高层事务的的逻辑流程。简单来说架构就是各个系统组件如何通讯、协调、以及控制操作的逻辑。可以类比人体的结构来举个简单的例子来理解就是：人体是由心肝脾肺胃、耳鼻嘴等多个重要器官组成，各个器官各司其职,它们之间相互配合共同维持人的正常生活。这里的心、胃等就是整个人体架构的组件,血液就是数据,血管就是传输数据的媒介,人的皮肤和长相就是用户的界面风格，逻辑组织就是食物要首先进入胃去消化然后才会进入大肠，而不是进入肾脏。按照这个解释，我们使用的kafka、redis、ssm、rabbitmq、xxljob等都是组件，这些组件各有各的作用，各自承担自己的责任去共同完成整个系统的高效流转。
常用的架构技术
分布式
分布式:将同一套业务代码按照业务功能或者自定义的维度拆分不同的子系统，各个系统分开部署,每个子系统叫做服务,每个服务之间一般通过rpc或者webservice来调用
分布式的优点
分布式的好处就是解耦了原系统，从而便于运维部署和水平扩展,提供软件的伸缩性,甚至服务可以通过不同的语言来实现.各个模块交给不同的人员去开发，每个人各司其职，出现问题也可以快速定位
分布式的缺点
分布式也并不是毫无缺点的,存在以下的问题:
①：服务调用通过网络来调用,一般微服务之间使用rpc来调用的，而rpc的底层就是TCP协议，如果网络故障或者延迟高一点,那么服务调用就有出现超时的可能性,比如dubbo的话会出现RpcException
②：分布式在业务体量比较小或者粒度划分的情况下就是一种灾难式开发，开发和运维的成本都会直线上升
③：分布式的数据一致性和事务比较难以保障,业务目前使用最多的是两阶段提交2pc,需要本地事务和远程事务综合提交,性能比较差
④：分布式session的维护在单体工程中是不需要考虑session的安全性的,而在分布式环境中就必须考虑如何去维护session的一致
⑤：分布式事务问题:分布式下如何保证各个服务的数据一致性也是一种挑战,当程序出现异常崩溃的时候能够保证各个服务能够正常回滚是很重要的。
分布式最常见的技术:分布式缓存、分布式存储、分布式计算、分布式静态资源
集群
集群:同一套代码部署在多个服务器上,而多个服务器可以提供更多的cpu、内存、硬盘等资源，从而提升整理的处理请求能力。集群的每个服务器叫做节点,每个节点提供的是相同的服务,节点的关系只是一种简单的复制,具体是哪个节点处理,则是根据负载均衡策略来决定；在网站的处理能力出现下滑的时候,简单的在集群中增加服务器台数就可以显著增加整体的数据量处理能力(不过存在上限)；
原理很简单:所谓众人拾柴火焰高,多台服务器一起聚合处理数据量和并发访问的能力肯定比单台服务器要高很多；在遇到请求处理的瓶颈时候,可以通过简单的增加服务器台数来提高并行处理的能力,不过需要注意的是增加服务器台数在出现大于某个数量之后性能会停滞不前。
结束语：以上就是关于架构的基本知识的全部内容，更多内容请关注学步园。