架构的意义

题记:近日拜读陆泽西的书,颇有感悟.一些是我对书中内容的理解感悟和提炼

架构的意义
什么是架构？对于架构，每天都有人在耳边提起。但架构到底是什么，却很少有人说清楚。
网络上的解释包括：软件架构是一个系统的草图，软件架构是构建计算机软件实践的基础，以及软件架构是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计等。这些说法都对，但是阐述得还是有些模糊，懂的人本来就懂，不用看，而不懂的人看了还是一头雾水。“架构”这个词太抽象，难以准确定义，而现在的大部分图书和文章讨论的“架构”都是服务器端的部署图，所以大部分人一提到架构就觉得是几台服务器放这里或那里，用不同的软件连接合作，用各式的框架开发扩展等。希望这一章可引导读者认识到，架构无处不在，它实质上是解决生活和工作中问题的一种方案。除了自己着手寻找解决问题的方案外，还可通过其他方法，比如直接购买现成的，或者以外包及部分外包的形式，或者以合作模式等来解决问题，这些都是切实可行的方案，都是值得考虑的方案。我们所求的不是最贵的，也不是最高级的，而是最好用的。
在软件系统中，架构的重要性不言而喻，项目从研发到上线运营，我们要在不同的方案中选择合适的架构，例如，前端渲染引擎是自己研发，还是使用商业引擎？商业引擎是使用Unity.3D,还是Unreal或其他？具体到怎么用架构形容得更贴近实际生活一些。 可以把软件架构理解为软件程序的架子，与现实中的书架有异曲同工之妙，这个架子 上有很多大大小小的格子，每个格子里都可以放置固定种类的程序。架子有大有小，大的需 要花费点时间去定制，小的则轻便快捷。 架子的大小是由设计师决定的，设计师根据客户的需求设计，假如放置的空间大，且 需要承载的东西多，那么就往容量大的方向设计，让它能容纳更多的东西，能放置各种不同 类型的程序，反之则做得简约些，这样更容易理解，又轻又快。 架子完成后要拿出去用，如果一出现异常情况就倒了或散架了，就不算是一个好的架 子，架子的好坏可从以下几个方面进行评估。

1.承载力 书架上能放多少东西，能放多重的东西，是使用者（这里使用者可以为客户、玩家或程 序员)网注的问题。 果构的程序意义来说，一个架构能承载多少个逻辑系统，当代码行数扩展到100 万行时是否依代 够有序且规范地运行，以及程序员彼此工作的模块耦合度是否依然能保持 原来的设订婴求，能够承载多少个程序员共同开发，共同开发的效率又如何，这是对软件架构承载力的评定指标。 从架构的目标上来看、对于服务器来说，当前架构能承受多少人同时访问，能承载的 日均访间量是多少，这就是它承载力的体现。而对于客户端来说，能显示多少元素，可演染多少模型（包括同屏渲染和非同屏宣染），则是它的承载力的体现。 若访间量承载力太低，访问量一上来就都卡在加载上，大家就不会再有这个耐心来看 你的产品了、运营和宜传部门在导入流量时，效果就会大打折扣。同样，。 承载力是重要因素，但也并非是唯一因素，综合因素才是评定好坏的关键，一个点的 好坏并不能决定全盘的好坏，木桶效应里最短的那块木板才是产品好坏的关键。

2、可扩展性
如果书架上只能放书，这个书架的用途就太单一了，花瓶不能放、箱子不能放、鞋子 不能放、袋子不能放、衣服不能放，客户八成不买单。 架子能适应不同类型的需求，可添加不同类型的系统、不同功能的子系统，是非常必 要的。软件架构也是同样的，但要具备更多功能就必须有更高的可扩展性。 可扩展性的关键在于，是否能在添加新的子系统后不影响或者尽可能少影响其他子系 统的运作。假设添加了子系统后，所有系统都需要根据新的子系统重写或者重构，那就是灾 难，前面花费的时间、人力、物力和财力全都白费了，这是我们不想看到的，因此可扩展性 也是衡量架构的非常重要的指标。

3.易用性
易用性是架构师比较容易忽视的一个点。如果架构师设计了完整的架构，但具体执行 时被程序员认为不好用，这时架构师还是执着地推动它的使用，那么团队间就会加深矛盾， 这样开发效率就会下降。 这就好比在书架上取东西，如果需要先输入密码，再打开门，剥去袋子，拿出来，把 袋子放进箱子，关上门，当把东西放回书架上时，再来一遍以上所有步骤，这实在是太烦 琐，即使功能再多，承载力再好，使用者也会感到备受煎熬，这样，开发效率下降是自然的 事。甚至有些是机械重复的工作，精力和注意力都耗在了没有意义的地方，这种情况下，架 构师应该适时地改进架构和流程。 易用性决定了架构的整体开发效率，程序员容易上手，子系统容易对接，开发效率自 然就高，各模块、各部件的编写只需要花一点点精力来关注架构的融合即可，其他精力和注 意力都可以集中在子系统的设计和编码上，这才能让各系统各尽其职，将效率发挥到极致。

4.可伸缩性
还是用书架比喻，假设现在没有这么多书和东西要放，房子也不够大，那么书架如果 可以折叠缩小到我需要的大小则会更受用户欢迎，这就是可伸缩性的体现。 构能像我们制造的书架一样可随时放大或随时折叠缩小，那就太好了。当需要的承量没有这么大时可以不使用不游要的功能。化紫为简只启用的部分功能 这样就可以随时简化开发流程。 如，从服务器端的角度，当需要建高，做到能承载儿百万人同时在 时，服务器可随时扩展到几百上千台服务器来提高承载量到而在访骤减，或者平时 比较少，甚至低到只有几十个人访问时服务器可缩减到合机子运作，这样就大大缩 了服务器费用的开销，可以根据需要随时变更架构的承载力来节省成本。 从客户端的角度，伸缩力体现在是否既能适应大型项上，如上百人协同开发一个复 杂系统，也能适应小项目上，如1~3人小团队的快速开发环境，即小成本小作品的快速 迭 在实际项目中，有时可伸缩性看起来并不是关键的因素，很多人误认为伸缩性是程序 员的负担，甚至有的项目在某些时期根本不需要可伸缩性，只需要适应当前特定时间的需 求即可。这里不得不再次强调可伸缩性在架构中的作用，它是深入理解、设计架构的关键因 素，是做出优秀的完整架构的重要因素。

5.容错性
容错性以及错误的感知力 书架也会有磕磕碰碰的时候，同样也会出现因某处做工不精导致使用时歪歪斜斜的情况， 如果我们保证不了完全没有问题，至少需要保证它不会因为一点小小的毛病而彻底散架。 软件架构也是同样的，软件中的异常、Bug常有，我们无法预估设备何时损坏。容错 性起到了防止产品在使用中出现错误而彻底不能使用的作用，它需要有备份方案自动启用 功能，同时也能够让开发人员及时得知问题已经发生，以及问题的所在位置，最好能通过 Email或者短信、电话等方式自动通知维护者，并记录错误信息。 从服务 器端角度，容错性包括数据库容错性、应用服务器容错性、缓存服务器容错性， 以及中心服务器容错性，每个环节出现问题都会通知相关中心服务器改变策略，或者监控服 务器检测得知该服务器出现故障，自动更换成备用服务器或者更换链路。 从客户端角度，容错性包括当程序发生错误时，是否同样能够继续保持运行而不崩溃； 当这个页面程序出错时，是否依然能够运行其他程序而不闪退或崩溃。同时所有出现的程序 错误，都能及时地记录下来并发送到后台，存储为错误日志，便于开发人员及时得到详细的 错误信息，能够根据错误信息快速找出问题所在。 在架构中，以上这五项能力缺一不可，某项能力特别突出并不能决定整个架构的好坏， 要考虑综合因素。倘若哪一项比较弱，随着时间的推移，问题会不断地向该方向聚集，直到 最终出现大的问题，甚至崩溃。我们需要一个牢固的、多样化的、好用的、可伸缩的、有韧 性的书架，这也是我们在设计架构时所追求的目标。 万物相通，木桶原理也适用于架构设计，木桶上仅有一块或几块板比较长没有用，其 他短板照样撑不住多少水。这契合架构理论，好的架构本来就是由其所有子系统的架构来支 撑的，整体架构虽然比其他子系统的架构更具宏观性，但起不到决定性作用。
如何让所有因素有的方同发展，是架构师最终要考和解决 的问题。