谈谈架构设计的目的

今天主要谈谈这么几个问题? 第一、架构设计的目的是什么? 第二、架构设计的常见误区? 1 不做架构设计的系统难道就跑不起来吗? 2 设计良好的架构能促进业务发

今天主要谈谈这么几个问题?

第一、架构设计的目的是什么?

第二、架构设计的常见误区?

1.不做架构设计的系统难道就跑不起来吗?

2.设计良好的架构能促进业务发展吗?

第三、不是每个系统都需要做架构设计?

第四、为了高性能、高可用、可扩展,所以要做架构设计?

这四个问题摘自李运华先生在极客时间中的《从0开始学架构》专栏。

针对这四个问题,我想谈谈我的看法。因为在公司我的职责之一就是架构师,当然了,这个架构师并不是十分的专业。另外,对于架构师这个职位,没有个五到六年的积累称不上真正的架构师。

 

一、架构设计的目的是什么

针对这个问题,在我看来,为什么要架构设计,用一句话来概括就是:"架构设计的真正目的是为了解决软件系统的复杂度带来的问题"。

任何系统最开始都是非常简单的,比如像我在这家公司开发的第一个项目智能酒店系统,最开始仅仅只是房态图、会员、预定、报表、房价方案、房型、酒店、角色、员工、部门等不是特别复杂的功能,这些不是特别复杂的功能在现有的开源项目,有不少可以找到现成的解决方案可以节省很多时间。最早期看起有点复杂,实则不是特别复杂,到后来与对应的智能门锁系统绑定在一起,就慢慢变的开始复杂起来。当系统越来越庞大变的耦合性高、性能低下时,这时就不得考虑重构。即便是重构也需要十分谨慎,因为既要保证重构能解决这个问题,同时也要保证项目在线上的正常服务,所以这个过程就需要循序渐进。在这个循序渐进的过程中,一开始就得仔细设计。

怎么个仔细设计法?

我个人结合之前的经验,归纳为如下几个办法?

1.流程的梳理(主要是理清逻辑,看那些流程可以剔除或者是优化,除此之外,最好还是结合数据库,将表的逻辑理清,利于分库分表方案的进行);

2.根据最开始的文案(什么可行性方案、需求分析、概要设计、详细设计等),重新审慎;

3.代码结构梳理(主要是项目结构(一些分包之类是否合理,比如像filter的话,通常放在cn.companyname.projectname.filter这个包下,同时也包括代码是否规范,这个可以参考现有的阿里巴巴Java开发手册),同时这个梳理也是为了衡量是否有分模块的必要或者是是否放弃单体转向微服务的必要,当然了,也包括如果要这样做,所花费的成本是否值得;

 

二、架构设计的常见误区

1.不做架构设计的系统难道就跑不起来吗?

不做架构设计的系统同样也是跑的起来的,也能正常提供服务。比如敏捷开发为例,敏捷开发以用户的需求进化为核心,一开始并没有一个整体的架构思路,谁都不知道最后的项目会变成怎么样,因为一切以用户的需求进化为主。比如当初在开发智能酒店系统的时候,我们谁都没有想到将其与智能门锁绑定在一起。

另外顺便说说敏捷开发的核心原则,给大家普及一下。

敏捷开发的核心原则有这么几个?

(1)主张简单;

(2)拥抱变化;

(3)可持续;

(4)递增变化;

(5)投资最大化;

(6)有目的的建模;

(7)快速反馈;

(8)轻装前行;

 

2.设计良好的架构能促进业务发展吗?

这个问题可以分两个角度来看,好的和坏的。

好的角度来看,项目之初,良好的架构可以促进项目的良性发展,人无远虑必有近忧,设计之初将远的近的都考虑进来,最后会使得项目朝着好的方向发展,同时也会降低项目所投入的时间、金钱、人员等成本。

坏的角度来看,对于软件这个多变的玩意而言,很少有人能将所有的方面考虑到,即便考虑到了,还会有些遗漏,有一句话说的好,计划跟不上变化。就比如之前某家公司产品经理要求该程序员做出app背景根据手机壳来变色那样的变态需求。从这个例子可以看出,需求具有不确定性,这个不确定性不仅仅与人员有关,也与业务在实际上为客户服务有关。比如淘宝为例,淘宝刚开始,肯定没有现在的高性能、高并发、高可用等。演变都是根据实际情况而定,根据实际的情况采取不同的措施。

比如在上家公司做的是办公系统,办公系统对于性能方面的要求肯定不及电商。如果对一个对性能要求不高的系统采用高性能、高并发相关的措施是不是有点不合适宜,因为这些都是要烧钱的,从老板的角度看,最大程度降低成本,做出客户满意的产品。至于性能方面的(只要达到用户的期望,用的时候不卡顿就行)要求不高。

 

 

三、不是每个系统都需要做架构设计?

这里我引用李运华先生的观点。李运华先生对此是这样理解的?

他认为这是知其然不知其所以然,系统的确是要做架构设计,但却不知道为什么要做架构设计,反正就觉得大家都要做架构设计,所以做架构设计肯定没错。

这样的架构师或者设计师容易走入生搬硬套业界其他公司已有的架构歧路。一旦强行引入,很大可能会发现架构水土不服,或者运行起来很别扭,最后往往不得善终,要么推到重来,要么不断重构。

以此可以回答,系统是需要做架构设计的,前面说过架构设计是为了解决软件复杂度问题,项目之初,软件架构应该是简单、能实现业务这两个目的。再比如晚清时期洋务运动的失败,根本原因是因为不适合当时的中国国情。对于架构师而言,业界的确有很多不同或者大体相似的解决方案,但是究竟适合不适合公司,需要慎思。

 

四、为了高性能、高可用、可扩展,所以要做架构设计?

通常有这种观点的人,不算是真正的架构师,因为不是每一个系统都需要达到这三个条件,或者是就算系统达到这三个条件,最终不让客户或者是老板满意,那也是白搭。

 李运华先生,对此的看法是:如果架构师往往有“为了高性能、高可用、可扩展,所以要做架构设计”这样的想法并在实际当中这么做,那么将非常有可能会给项目带来巨大的灾难。

为什么会这样呢?因为这类架构师不管三七二十一,不管什么系统,也不管什么业务,上来就要去“高性能、高可用、高扩展”,结果就会出现架构设计复杂无比,项目落地遥遥无期,团队天天吵翻天等各种糟糕的现象,费尽千辛万苦,费尽九牛二虎之力将系统整上线,却发现运行不够稳定、经常出问题,出了问题难以解决,排查问题困难,加个功能要改一个月或者两个月。

我想有部分公司经常加班,与这个也许有一定的关系。

 

小结:

最后还是觉得要强调最开始说的那句话,架构设计的真正目的是为了解决软件系统的复杂度带来的问题。同时补充一句,不是为了追求所谓的高大尚。