你真正思考过什么是架构吗？.docxVIP

你真正思考过什么是架构吗？ 2021-08-26 更多内容关注：fullstack888 前言：在这个学问共享的爆炸时代,鉴于java生态的完整和富强,各种框架、两头件和工具包供我们使用。连新培训出来的人都晓得ssm,微服务、集群、多线程、队列、高并发等技术,技术的间隔性正变得越来越小,仿佛我们只需要按部就班的去使用别人说的框架等技术就可以处理问题.假如刨除redis、rabbitmq、kafka、dubbo、springcloud这些具体的技术框架，你有没有静下心来真正思考过架构是什么呢？这些框架是到底是扮演怎样样的角色？假如让你给架构下一个定义,你会选择如何去描述架构呢？ 背景: 从当时流行的框架是spring、struts2、hibernate,前端使用的是jsp，业务也不是那么简单，整个项目并发量并不大,QPS都不会超过5,当时的做法全部的前端和后端放在一起部署,打成war包直接部署到centos上的tomcat上就可以运转了,这样完全可以承载实际生产环境的恳求量,问题也不大。后来当我换了一家公司,公司接受dubbo微服务化,全部的业务均被划分成了一个个服务来供应应接口调用,当时的业务场景也比以前的简单,接受23台服务器分开部署,容纳的线上负载或许在几百万左右.服务进行修改规律再也不用像以前那么麻烦需要把整个项目重新打包再部署了.之后就在微服务的路上走的更远了,全部的服务独立部署,打包成镜像文件成为docker实例，独立部署在docker的服务器上,结合git,部署、运维、开发的效率得到了快速提升 ? 一：架构到底是什么 架构到底是什么？首先来看一下维基百科对架构的解释: 软件架构：是一个系统的草图。软件架构描述的对象是直接构成系统的笼统组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些笼统组件被细化为实际的组件，比如具体某个类或者对像。 软件架构师：软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、规律和流程 依据维基百科的解释：软件架构实则是各个组件的相互搭配和组件之间的相互协作,是笼统的高层事务的的规律流程。简约来说架构就是各个系统组件如何通讯、协调、以及把握操作的规律。可以类比人体的结构来举个简约的例子来理解就是：人体是由心肝脾肺胃、耳鼻嘴等多个重要器官组成，各个器官各司其职,它们之间相互协作共同维持人的正常生活。这里的心、胃等就是整个人体架构的组件,血液就是数据,血管就是传输数据的媒介,人的皮肤和长相就是用户的界面风格，规律组织就是食物要首先进入胃去消化然后才会进入大肠，而不是进入肾脏。依据这个解释，我们使用的kafka、redis、ssm、rabbitmq、xxljob等都是组件，这些组件各有各的作用，各自担当本人的责任去共同完成整个系统的高效流转. 二：常用的架构技术 2.1：分布式 ? ?分布式:将同一套业务代码依据业务功能或者自定义的维度拆分不同的子系统，各个系统分开部署,每个子系统叫做服务,每个服务之间一般通过rpc或者webservice来调用 2.1.1: 分布式的优点 分布式的好处就是解耦了原系统，从而便于运维部署和水平扩展,供应软件的伸缩性,甚至服务可以通过不同的言语来实现.各个模块交给不同的人员去开发，每个人各司其职，消灭问题也可以快速定位 2.1.1:分布式的缺点 分布式也并不是毫无缺点的,存在以下的问题: ①：服务调用通过网络来调用,一般微服务之间使用rpc来调用的，而rpc的底层就是TCP协议，假如网络毛病或者延迟高一点,那么服务调用就有消灭超时的可能性,比如dubbo的话会消灭RpcException ②：分布式在业务体量比较小或者粒度划分的情况下就是一种灾难式开发，开发和运维的成本都会直线上升 ③：分布式的数据全都性和事务比较难以保障,业务目前使用最多的是两阶段提交2pc,需要本地事务和近程事务综合提交,功能比较差 ④：分布式session的维护在单体工程中是不需要考虑session的平安性的,而在分布式环境中就必需考虑如何去维护session的全都 ⑤：分布式事务问题:分布式下如何保证各个服务的数据全都性也是一种挑战,当程序消灭特别崩溃的时候能够保证各个服务能够正常回滚是很重要的。 分布式最常见的技术:分布式缓存、分布式存储、分布式计算、分布式静态资源 2.2：集群 ? 集群:同一套代码部署在多个服务器上,而多个服务器可以供应更多的cpu、内存、硬盘等资源，从而提升整理的处理恳求力量。集群的每个服务器叫做节点,每个节点供应的是相同的服务,节点的关系只是一种简约的复制,具体是哪个节点处理,则是依据负载均衡策略来打算；在网站的处理力量消灭下滑的时候,简约的在集群中添加服务器