实例学架构设计之源起复杂度

要点:

架构设计主要是解决系统的复杂度问题

作为一个长期在一线的开发人员我们听得最多的词语莫过于架构,比如我们常常开发的web网站他是B/S架构的,企业用的ERP好多都是C/S架构的。我们往往不假思索的此脱口而出,很少去探究为啥需要如此设计架构。今天我们先探讨什么是架构和为什么需要设计架构。

现代人对于架构这个词并不陌生,架构通俗点说就是结构,就是组成为了达到系统正常运转的目标系统各个部分在系统中所占的位置以及他们的联系,他是大生产的产物,是人类发展过程中不断演进的结果。每个信息系统同样存在着类似人类发展过程,在系统发展的初期我们系统比较简单,功能也很少一个程序几行代码就足以满足需求保证业务的顺利运行,随着业务的发展系统功能也越来越多,系统越来越复杂,渐渐的系统如同一团乱麻,各个功能互相调用,代码高度耦合,这样既降低了系统的稳定性也让系统越来越难维护,就像早高峰的十字路口没有了信号灯一样,系统很快陷入了瘫痪,无法再发挥他的作用了,最终宣布死亡。作为开发者谁都不想自己的系统以这样的方式退出历史舞台,先驱们开始将人类社会中分工合作的生产方式引入软件的过程中,让系统的各个部分承担自己的职责,每个部分与其他部分统一通信方式,逐渐就形成了一些统一的架构体系比如B/S,C/S。总之业务的发展带来了软件的壮大,软件的壮大引起其内部无比复杂,复杂的系统必定会爆发各种各样问题,为了解决这些问题于是产生了架构,他是解决系统复杂度有效方法之一。

既然说这是之一 那么就还有其他的方案咯? 对的。软件这么多年的发展史就是和复杂度不断斗争的历史。我们经常听说的代码重构和设计模式就是解决系统复杂度方案,他们主要解决的问题是软件开发过程中代码复用和功能扩展的问题,使系统内部能够高内聚低耦合,方便新功能的扩展和维护。那么系统架构的设计解决了系统的哪些复杂度的问题呢?首先他站在一个整体的高度规划系统的功能,制定好系统与系统之间的沟通方式,异常的处理方式等,这样可以保证系统在开发之前就能与现有外界系统或者各子系统之间联系,使系统不至于成为一个信息孤岛。其次系统架构设计是站在系统运行和维护的角度去思考系统,把每个系统在真实环境中有可能遇到的问题进行评估和推演,给出最合适的解决方案。最后系统架构设计会预计系统未来发展的方向,为未来业务支持预留好接口。

随着互联网时代的到来,大数据和人工智能的不断兴起,架构设计越来越具有挑战性了。我们以前开发的系统的服务对象基本上都是企业内部,主要目的就是帮助企业实现信息化,每做一个系统主要解决的是业务的某一类问题,系统使用人数数据流量,对于实时性要求方面都不是那么精确。在互联网公司系统却完全不一样,以电商平台为例,他面对的是海量的户,承受的是千亿的请求,运行的是百变的业务,系统的复杂度远不是一个企业内部系统能够类比,当然我也不是说企业内部系统都是小菜,在企业内部系统逐渐完善的今天,具体挑战也不是,主要集中在如打破信息孤岛,如何挖掘潜在机会上面。架构设计的挑战就来着于大量数据,大量请求所带来的可用性,高性能,可扩展性,安全性,低成本,规模。

写了这么多废话,我总结一下架构设计主要是解决系统的复杂度问题,系统的复杂度主来着于系统运行过程遭遇高性能,可用性,安全性,低成本,规模化等问题。系统架构设计也围绕着系统遇到的问题逐个评估解决。

可用性

猜你喜欢

转载自www.cnblogs.com/jimfighting/p/9920493.html