读架构之美

     自开始写代码起,就开始听说“架构”这个词,一直没有深究其中的含义,近来翻起《架构之美》这本书,想想谈起架构有些问题是接踵而来。

     第一、什么是架构

        架构是一个过程,而非结果架构是一个持续该井的过程。架构的最终产出物是一张图 。一张引导实施的图;一张目标系统的图。

        架构通常体现为一组结构。

        每种结构都由各种类型的组件及其关系构成。组件可以是建筑中的支架横梁,也可以是内部腔室。

        每个学科都有自己的一套组件和组件间的相互关系。

        每一种结构都是为了帮助我们理解如何来满足特定的关注点,展示关注点是如何被满足的。同样也展示某些关注点被满足时,是如何影响到其他关注点被满足的。

          架构还体现为一组行为。

          行为又可分为外部行为和内部行为,外部行为展示了系统如何与用户、其他系统之间的交互。内部行为体现为组件之间的交互接口。     

 

     第二、怎样的架构才算是一个美丽的架构

           美丽至简,精益并且是不断演进式发展。精益在于避免过度设计,同样使得架构能不断演进。无论是一个大规模的电信网络管理系统、大规模应用的互联网架构还是企业级的ERP系统,很多时候不可能一开始就设计出最完美的解决方案。系统应该随着规模的变化,不断演进。这样的系统才是科学的、经济的。

 

          架构之美体现在关注点的分离和结合。在软件设计中,我们需要考虑多方面的关注点,漂亮的架构就是让这些关注点尽可能分离,然后以最简单的方式结合,从而得到高内聚、低耦合的系统。 

 

          架构之美还在于解决实际问题,它既是艺术的也是生活的。从艺术的角度说,美是创造矛盾并解决矛盾。架构的多关注点和表达的简洁性是一种矛盾,而架构之美就在于解决了这个矛盾。

          

           架构的评估方式一般有几种

          A、确定架构属性,通过建模或者模拟系统的一个或者多个方面。

              如,通过性能建模来评估系统的吞吐量和伸缩性;通过失效树模型来评估系统的可靠性和可访问性,还有复杂性和耦合性指标,可用于评估可变性和可维护性。

          B、通过对架构师的质询来评估架构。

              有许多结构化的质询方法,通过组织内的专家或者一些领域专家的质询来评估架构。 

          C、架构折中分析法。

              这是质询评估法的变体,它通过寻找架构中不能满足品质关注点的风险来评估架构。使用特定场景分析,每种场景描述特定利益相关人对系统的品质关注点。然后由架构师来解释如何支持每一种场景。

 

     第三、如何成就一个美丽的架构

         第一、要明确系统的关注点。

                 要明确系统需要考虑哪些关注点、哪些关注点是需要重点考虑的关注点。没有一个系统能够完美地满足所有关注点,对其中一个关注点的完美满足就是对另外一个关注点的不完美满足,所以架构是一种折中,一种针对特定系统重要关注点的折中满足。发现特定系统中的重要关注点,以及满足这些关注点的条件,是我们取得架构的方法。

                 另外,项目中的不同群体对系统有不同的关注点。如

                 投资人:他们关注的是项目是否可以在给定的资源和进度约束下完成。

                 架构师、开发人员、测试人员:他们关注的是系统最初的构建和以后的维护、演进。

                 项目经理:他们关注的是如何组织团队,指定迭代计划。

                 客户:关心的是所有关注点是否得到了合适的满足。

                 与相关利益群体沟通、明确这些关注点和约束,并为他们排列优先级。


         第二、是一组要遵循的规则。

                这组规则有助于消除复杂性,并可以用于指导详细设计和系统验证。设计规则可能表现为特定的抽象,这些抽象总是以同样的方式使用;设计规则还表现为一种模式,如管道模式和过滤器模式,在系统中处处使用相同的设计原则,设计概念具备完整性,一个好的架构反应的是一组设计思想,而不是很多好的思想,这些思想之间却彼此独立不协调。设计规则还体现在符合法规和安全性的要求。

         第三、 确保设计概念在实现时得到一致体现。

         第四、好的架构来自于更好的架构师提供的现场指导。原因在于一些关注点是很多系统的共性

                 1、功能性

                     产品向他的用户提供哪些功能

                 2、可变性

                      软件将来可能要哪些改变,哪些变化不可能发生改变,不需要特别容易做这些改变

                 3、性能

                      产品将达到怎样的性能

                 4、容量

                      多少用户将并发使用该系统?该系统为多少用户保存数据?

                 5、生态系统

                     在部署的生态环境中,该系统与其他系统进行哪些交互?

                 6、模块化

                     如何将编写软件的任务分解为工作指派?特别是这些模块如何进行独立开发?并能够准确而容易地满足彼此的需要。

                 7、可构建性

                     如何将软件构建为一组组件。并能够独立实现和验证这些组件?哪些组件应该复用其他的产品?哪些应该从外部供应商处获得?

                 8、产品化

                     如果产品将以几种变体的形式存在,如何开发一个产品线?并利用这些变体的共性?产品线中的产品以怎么样的步骤开发?是否可以开发最小的产品,然后再添加、扩展组件。在不改变以前编写的代码情况下,开发产品线的其他成员?

                 9、安全性   

                     产品是否需要用户认证?数据的安全性如何得到保障?如何抵挡外来的攻击? 

 

     最后想说的是,架构之路并不平坦,需要我们不断探索,不断实践。在自己的成长之路上,每一滴汗水才是自己成长的记号。《金刚经》云:“一切圣贤皆,以无为法而有差别”。

 

 

 

你可能感兴趣的:(读架构之美)