河南梦之网网络科技有限公司
梦之网科技出品
扫描关注梦之网科技微信公众账号

扫小程序码联系客服

技术架构的战略和战术原则-梦之网科技

梦之网科技2019-10-09文章动态

技术架构,是将产品需求转变为技术实现的过程。技术架构解决的问题包括了如何进行纯技术层面的分层、开发框架选择、语言选择(这里以 JAVA 语言为主)、涉及到各自非功能性需求的技术点(安全、性能、大数据)。技术架构是确定组成应用系统实际运行的技术组件、技术组件之间的关系,以及部署到硬件的策略。

技术架构面临最大的挑战是“不确定性”。在技术架构上,很多时候就会面临这种选择。是要选择业界最新的技术?还是选择团队最熟悉的技术?如果选择最新的技术,遇到新技术出了问题怎么解决?如果选择目前熟悉的技术,后续技术演进怎么办?这些都是架构师在做技术架构过程中需要考虑的。

业务在千变万化、技术在层出不穷,没有一套通用的技术架构模式来适用所有的系统。那么,我们如何保证在做技术架构时,能够实现一个稳定、出色的系统。面对这些“不确定性”时的架构设计问题,这里从战略和战术两个层面来提供一些设计原则。战略层提供的是技术架构的方法和思路,属于顶层设计;战术层提供的是技术架构的技术实践方式,更偏向详细设计。

战略层设计原则

战略层的设计原则就是:合适原则、简单原则、演化原则。

1.1 合适原则

技术人员有一种很强的技术情怀,就是在做设计的过程中,很希望挑战新的技术、在项目中采用最新的框架、或者自己重造一个比业界的还要牛的轮子。这样才能够显示出自己的优秀,以至于不让自己显的那么平庸。比如,在项目中重新造一个能够解决亿万级数据的新的 xx 流式计算技术,比 flink 还要牛一百倍;有或者在项目中使用最新的 xx 技术,能让系统承担亿级用户的访问。

那么现实是,如果在设计过程中一味追求新技术,往往失败的可能性很高。

没有那么多人,却想干那么多活

现实环境中我们一个业务团队可能就十几个人,项目工期短、上线要求快。在这种情况下,如果还要抽调几个人去研究、搭建、维护新的技术框架,对于项目势必会造成延期的影响。

没有那么多积累,却想一步登天

很多业界领先的方案,不是一帮优秀的开发加在一起,加班加点就能做出来的。而是经过几年时间的发展才逐步完善和初具规模。如果我们也想自己做一套类似的技术,不是说不可能。我们需要集合当下的技术实力、技术积累,做出适合自己团队情况的技术评估。

没有最新,只要最合适

所有新的技术刚出来都是打着比旧技术拥有更加出色的性能、提供更加优秀的扩展性。是不是使用新技术,就能解决一切问题了?新技术的出道,势必是解决某一场景下的问题,并不是一味万能良药。只有了解清楚每种技术的产生背景,适用场景,才能出一个对自己项目最优的选择。技术选型没有最新,只有最合适。

总结一下,合适原则就是适合优于业界领先。

1.2 简单原则

我们总是希望能将我们的软件设计的精美、宏大,这样才能彰显我们系统的复杂度和难度。我们是不是会遇到这样的场景,在做设计方案的时候,如果一个解决方案很简单,而且能很快的满足需求。在评审方案时,就会有人觉得这个方案是不是太简单了,没有什么技术含量,是不是需要再设计的复杂一点。

系统是不是一定要设计的复杂?在回答这个问题前,我们先看下软件领域的结构复杂性和逻辑复杂性。

1. 结构复杂性

结构复杂的系统有两个特点:第一,组成的组件数量很多;第二,这些组件之间的关系很复杂。如下图:

图 1

结构上的复杂性存在的第一个问题是,组件越多,就越有可能其中某个组件出现故障,从而导致系统故障。假设组件的故障概率是 1%(有 1% 的时间不可用),那么 2 个组件的系统可用性是 99%*99%=98%,5 个组件的系统可用性是 99%*99%*99%*99%*99%=95%,两者相差 3%。说明组件越多,系统稳定性就越差。

结构上的复杂性存在的第二个问题是,某个组件改动,会影响关联的组件。比如上图中 C 组件发生改动,会影响 A、B、D,而 A 有会影响 E。这样就会形成一连串的多比诺效应。

2. 逻辑复杂性

意识到结构复杂性的问题后,只要减少组件就能让系统结构变简单?这样做还是行不通,原因在于除了结构的复杂性,还有逻辑的复杂性,如果一个组件的逻辑太复杂,通用会带来问题。

我们试想一下,把淘宝的所有功能都在一个组件中实现,可以想象这个系统要有多庞大:几百人维护一个系统、代码分支几十个、需求变更应接不暇、不同分支的回归测试、修改一段代码可能影响整个系统的运行等等。这些场景相信大家都不希望看到的。

总结一下,简单原则就是大道至简。

1.3 演化原则

文章关键词
架构
软件架构
消息队列