架构设计的一些原则


规则1、误区:不写代码就慌张。先做设计后写代码

软件最后运行,交付的是可运行的代码,没有帮助手册,还可以应付过去,没有设计文档,也没关系,只要程序可以运行就可以了。这是大多数人无法做架构师的主要原因。他们认为,完成可执行的代码,才是最主要的。

如果你是一个团队的leader,带过几个人,那么你就应该理解这一点了,因为新同事,总是会这样去工作。

不全面考虑,想到一种方法就开始设计,开始编码,是非常错误的。 在错误的方案上做了设计,写了代码,最后交付了错误的软件。 不设计,就写代码。不写代码就心慌,是码农的原罪,是无法进阶,甚至被淘汰的导火索。

有一个同事,曾经有个项目要写一个复杂的流程,还带审批功能,这位同事觉得时间很短,二话没说,就开始按照自己的理解写代码了。 写了1个月,还是没有实现基本的流程功能,错误、bug都很多。 这就是典型的没有设计,出现的问题,如果该同事花1周仔细设计、调研,他会发现activiti、JFLow这类优秀的开源流程引擎,可以使用。

流程引擎

当你如果把代码写完了,你的架构师或者你的leader才知道,你在这样做的话,估计火冒三丈,再好的脾气也无法平息项目将要失败的怒火


规则1、不要过度设计

过度设计和过去消费一样不好,过去消费带来的快感很可能就会被还款压力所替代,过度设计也一样。

过度设计的原因:

  • 心理原因:总觉得需要设计一个样板出来,总觉得方案不是最完美,无法实现自己的设计理想。

过度设计的带来的不好,是可能带来成本的增加,发布时间的不确定性。

如系统只有1000人访问,就没必要考虑高性能的问题,数据库分库分表,也可以不用考虑。

过早的考虑分库分表,会让系统非常复杂,同时,我们需要评估人力、人员的水平,一般的工程师可能就2-3年工作经验,对于他们来说,这样的设计是比较难的。


规则2、扩展性必不可少

凡是一个需要不断迭代、3,4个人一起开发的软件都需要做一个架构,简单的也好,复杂的也好,架构就是旅游之前做的攻略,如果没有这个攻略可能在旅途中浪费很多时间,也可能很多美景无法观赏。

对于架构比较常说的有2个特性:扩展性、伸缩性,后文我们详细说明一下这2个概念的区别。

扩展性白话解释:

当新增功能和需求时,对现有代码改动较少,甚至不改动,对新功能的涨价非常方便,以前做架构时,就考虑到新增的特性。基础设施不需要经常变更,应用之间较少依赖或耦合,可以对需求变更快速响应。

  1. 举个例子:

我们看到开源软件,有很多版本变迁,在1.0版本的时候,就已经设计了2.0的支持的特性,这就是架构师设计了扩展性。

  1. 再举个例子:

设计模式中有 开放闭合原则,对于扩展是开放的,对于修改是封闭的,举例来说,我们写了一个数据库的sdk,以前只支持mysql,现在想支持pgsql,那么以前的sdk不需要怎么改变,只需要安装以前sdk的接口原则,新增pgsql的实现,就可以了。这就做到了扩展性。


扩展性举例:使用消息队列来提高扩展性

举个例子:

以登录这个例子为例,最初我们的网站登录功能很简单,随着业务系统的复杂化,登录这个功能越来越复杂。

需求 功能列表
第1期需求 通过用户名、密码登录
第2期需求 1、用户登录多次如果密码出错后,需要发送短信通知用户;2、检查登录的ip地址是否是经常用的ip地址,当在不通的城市登录的时候,需要短信提示;3、记录登录的细节信息,用于统计、推荐系统分析。
第3期需求 1、登录后,如有未付款账单,需要推送给用户。2、用户有快递信息,推送给用户

通过消息队列提高扩展性

消息队列基于发布——订阅模式工作,消息发送者发布消息,一个或多个消息接收者订阅消息。消息发送者把消息发送至分布式消息队列后就处理完毕,然后由消息订阅者从消息队列中获取消息进行处理。对于新增的业务,只要对某个消息感兴趣,就可以订阅该消息,而这对原有的系统和业务没有任何影响,从而实现系统的可扩展性设计。

我们可以把这种使用消息队列的扩展性,叫做 线性扩展性


规则3、伸缩性值得考虑

伸缩性一般指物理伸缩。指系统通过增加或减少硬件水平从而提升或降低系统性能的难易程度。可伸缩性分为scale up和scale out。scale up是指提高单台服务器的硬件水平来提高系统的整体处理能力,可以调整的有CPU,存储,内存等;scale out是指通过增加系统的处理节点的方式来提高系统的整体处理能力。

当然除了增加减少服务器,有可以通过增加、减少程序的实例的方式来达到伸缩性。


伸缩性例子: k8s弹性伸缩

弹性伸缩式k8s中的一大亮点功能,当负载大的时候,你可以对应用进行扩容,提升pod的副本数来应对大量的流量,当负载小的时候可以对应用进行缩容,以避免资源浪费。

举个例子:当微博某个话题非常热的时候,我们可以自动多部署几个话题服务,当话题热度降下来的时候,可以把多个一些话题服务给删除。


伸缩的分类:水平伸缩、垂直伸缩

水平伸缩: 1. 1个2,2变3个实例

伸缩性之水平伸缩

垂直伸缩(纵向伸缩):

  1. 通过自动配置资源请求来减少运维成本。
  2. 在提高集群资源利用率的同时最小化容器出现内存溢出或 CPU 饥饿的风险。

垂直伸缩


规则3、不要鲸吞,要蚕食,迭代原则

罗马不是一天建成的,长城也不是。

规则:不要鲸吞,要蚕食,一步一步来,追求迭代原则

变化是互联网的精髓,软件架构不可能一层不变,所以不要追求最终形态。

QQ1.0 到现在应该已经是不同的架构了。

汽车从最开始,到现在的电动汽车,也更新迭代很多版本了。发动机都变了。

QQ迭代历史

在发展中,有的软件继续了,有的死亡了。