什么是软件架构什么样的架构才是好架构？

什么是软件架构什么样的架构才是好架构？

　　广州华资软件,ssr软件下载,编程序的软件我们可能经常会听到有人说架构一词，但是到底什么是架构，却很少有人说的清楚。

　　网络上有人解释软件架构是一个系统的草图，软件架构是构建计算机软件实践的基础，是一系列相关的抽象模式。

　　这些说法不能说不对，但是解释的还不够清楚，因为不懂的人还是不懂，懂的人一眼就能看懂。

　　很多人以为计算机里面的架构，就是几台服务器放这里用不同的软件连接起来，用各种的框架开发扩展等等。

　　其实架构无处不在，它不只在计算机中存在，它在我们生活当中也很常见，比如我们着手解决一些问题，首先要计划一套方案，一套流程，这些方案和流程其实就是一种架构。

　　在软件系统中，架构是非常重要的一部分，它统领各个模块的开发和合作，项目从研发到上线运营，我们要在不同的方案中选择合适的架构，比如，我们服务器使用什么操作系统？使用什么语言开发？数据如何获取和存储？客户端使用什么框架开发？

　　这些问题的方案组合在一起就是一种软件开发架构，项目组的每个子系统都要有自己的方向，把子系统的决策方向合起来再加入它们之间的关联调用就构成了一个完整的架构，每个系统、组件、模块都是软件系统架构的一部分。

　　一个好的架构师，不仅需要对每个功能模块的方案进行深思熟虑，还要结合其他系统以及整体系统的需求方向进行设计。

　　可以把软件架构理解成一栋房子的框架，与现实生活中的房子有异曲同工之处，这个框架有很多个大大小小的房间，每个房间可以放各种类型的东西。框架可以做的很大，也可以做的很小，关键看你的需求。

　　框架的大小一般是根据客户的需求由设计师设计的，比如，需要放置的空间大，且需要承载的东西多，那就需要设计大的房间，让它容纳更多的东西。

　　框架设计好后，拿出去给其他人使用，如果出现异常情况就倒塌了，那它就不算一个好的架子，架子的好坏可以根据以下几方面判断：

　　比如一栋房子，能承载多少人能做多少个房间，是客户比较关注的问题。从软件架构方面来说，一个架构能承载多少个业务系统或功能系统，能承载多少代码行数，在达到规定的代码量时是否能有效正常的运行，是程序员和客户都关注的问题。

　　对于服务器来说，服务器的架构能承载多少人同时访问，能承载的日均访问量是多少，这就是它承载力的体现。

　　对于客户端来说，它能显示多少个UI功能，可以同时渲染多少个模型，分辨率可以达到多少，则是它的承载力体现。

　　承载力是重要因素，但是也不是唯一的因素，综合的评定一个架构的好坏是关键，就和木桶效应那样，决定产品好坏的关键是那根最短的木板。

　　如果一栋房子只能住人，不能放其他的东西，那么这个房子的设计用途就太单一了，大的家具不能放、长的家电不能放、特殊的水电不能装，那这个房子肯定没人买。

　　架构就是要适应不同类型的需求，可添加不同类型的系统、不同功能的子系统，是非常有必要的。

　　可扩展性的关键就在于，在添加新系统新功能的时候，会不会影响其他系统，添加这个新系统的代价大不大，会不会导致系统整体性能问题。

　　如果添加一个新系统，导致其他系统使用有问题，那么这个架构的可扩展性就很差。

　　易用性其实很简单，就是你这个产品设计的好不好用，是不是方便使用，这个可能是很多架构师会忽略的一点，因为大部分架构师只是一个程序员。

　　程序员很少会从客户的角度去想问题，所以就会导致设计出来的东西不符合客户的使用习惯。

　　易用性也决定了软件的整体开发效率，因为一个好的架构，会让团队成员容易上手，子系统容易对接，开发效率高，各模块和各系统的编写只需要关注系统的设计和编码工作，其他模块通信方面的事情，架构可以提供很好的兼容。

　　什么是伸缩性？其实就是你设计的这个方案或系统是否可以根据需求适配不同数量的功能或子系统，比如一栋房子由于住的人比较多，它的框架是否可以分割成多个房间，当人数变少的时候，能不能根据根据需求把多个房间合并成一个大单间?

　　这就是可伸缩性，在我们设计的软件系统中，架构的可伸缩性决定了架构的可适配性，比如，当这个系统使用人数较少的时候，是否支持减少一些服务器来支撑服务端的运行，当系统使用的人数较多时，访问量较大时是否支持添加服务器来增强系统的支持。

　　房子也会有损坏的时候，同样也会出现某个地方做工不好，导致使用的时候出现各种破损，我们保证不了完全没有问题，但是需要保证它不会因为一点小问题，出现倒塌的情况。

　　软件架构也是这样，如果软件中某个系统出现了一点小BUG导致整个系统使用不了，那这个架构容错性就很差，软件中的一些BUG很常见，我们无法避免，但是我们应尽量保证这个BUG的影响范围最小。

　　同时，若出现系统无法使用的情况，应该有备份方案，比如自动启动或者自动保存数据等功能，也应该能够让开发人员及时知道问题的发生，以及问题所在的位置并记录错误信息。

　　在架构设计中，以上五项基本能力缺一不可，某项能力的突出并不能带动其他项，也不能决定整个系统的好坏。

　　但是如果某一项能力比较弱，随着时间的推移，问题会越来越大，甚至系统崩溃。就像木桶原理那样，一个木桶的容量不是取决于最长的那根木板，而是取决于最短的那根。

　　我们需要一个坚固的、多样化的、好用的、可伸缩的、容错性强的房子，这也是我们设计架构所追求的目标。