架构随聊

一、架构的定义

所谓一千个架构师中有一千种“最好的架构”模式。

  “架构”是我们这行业种一个很常见的词,表明其必然也是经历了很长的岁月打磨所形成的一个词。架构的这个词出现的意义是什么?为了解决什么问题?只有把这2个问题想明白了,才能设计出一个良好的项目架构。

  我认为 架构类似于画房屋设计图,在刚开始我们盖一层楼的小房子的时候,拍拍脑门想一下,脑子里有个大概的样子就开始动工了,想怎么盖就怎么盖,大部分情况下也都不会出现。但是当你要盖一个大楼,这时候拍拍脑门的方式虽然有可能还能管用,但是由于没有经过深思熟虑的多方考量,建造出来的必然是问题重重。另外建造大楼和盖个一层楼的小屋所需的团队规模肯定是不同的,每个人心中的标准不同,如果没有一个统一的规范,最后的结果可想而知。所以架构就是定规则做限制,是在权衡各方得与失之后的一个“最合理决策”,由它来指导团队中的每个人思想层面上的一致,使得最终的产品达到像由一个人做出来的一样。另外还有控制复杂度、提高团队协作力、降低成本等等作用。

  在软件开发中,架构的意义不单单是为了让团队达成一致,因为我们工作的本质是为了做出更好的支撑业务发展需要的软件产品,所以架构也是基于业务的架构。我认为一个好的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。我相信大部分在中小型公司呆过的人应该都经历过被业务推着走的时代,每天焦头烂额的这里卡了,这里挂了,这里报错等等问题。当我们遇到这些问题的时候是时候花成本来考量当前的架构是否存在问题?

二、如何开始设计一个架构

做架构的最重要的一点就是上面说的贴合业务,任何不基于业务做异想天开的架构都是耍流氓~

  架构不是像平常写代码一样,对就是对,错就是错,它并无对错之分,是一个取舍的过程。当我们从0开始做架构的时候,的确是比较困难。虽然万事开头难,但是一个好的开始相当于成功了一半,会给我们接下去的工作打下结实的基础。 

  下面来阐述一下笔者个人是如何从头开始做一个架构的,供大家参考学习:

  1.架构是一个整体--> 部分的过程,先得明确整个公司/组织对外提供的服务是什么?这是最上层的战略架构,这个基本是一旦确定就很难甚至无法更改了。

  2.给每个部分(比如SOA的某个服务)划分解决方案。比如根据公司的组织架构或者产品等。

  3.找到每个解决方案的核心功能和支撑功能。并形成一个业务总览图

  4.分久必合,合久必分,结合当前的实际资源情况做出最终的决策,这是整个过程中最耗时的点,它决定着架构的复杂度和开发成本。方式上包括但不限于抽出可重用的功能、功能的组合、拆分粒度更细的功能提高可重用性等等。这一切的决策都要以“恰到好处”为宜。千万不要盲目的跟从微服务之风!千万不要盲目的跟从微服务之风!千万不要盲目的跟从微服务之风!重要的事情说3遍。服务粒度越细,调用链路越复杂,带来的开发成本是否适合团队,是作为一个架构师需要着重考量的点。

  5.确立每个功能块之间的协作方式,包括但不限于通讯方式,通讯协议,依赖关系等。

  6.最后要把这些形成最终的架构总览图,这样能够帮助站在一个更高的角度去考虑架构的演变问题。如果是针对现存项目重新做架构,那么需要把现有项目架构梳理出来,作为我们上面思考过程中的一部分参考信息。

三、一个好架构的特点

首先从心态上必须要有工匠精神,因为软件架构和造房子还是有不同的,它不是一开始就一步到位的,好的设计肯定需要经过反复的修改,从简单到复杂的循环验证,不断的打磨。

  方向上我认为分以下几个点:

  1.文档化:不管是整体还是部分的整个生命周期内都必须做好文档化,变动的来源包括但不限于BUG,需求。

  2.高可用:要尽可能的提高软件的可用性,我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。

  3.安全:组织的运作过程中产生的数据都是具有商业价值的,保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段

  4.可扩展:软件的设计秉承着低耦合的理念去做,注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代,并且支持在适时对架构做出重构。

  5.快速迭代:拥抱变化,占领战略先机。

  6.高度自治:为了更好支撑第4点和第5点的,每个功能能够高度自治带来的好处是可以快速迭代,并且不管是功能迭代还是技术迭代所对整个系统的影响降到最小。

  7.高复用:为了避免重复劳动,为了降低成本,我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。

  8.可验证:一个好的框架需要考虑到各种特殊情况,并且是可以进行专项验证的。

四、做架构中的误区

做任何事的时候需要不断的跳出原来的思维角度重新审视,这样才能避免陷入泥潭。列出几个我能想到的误区:

  误区1——架构专门由架构师来做,业务开发人员无需关注:架构的再好,最终还是需要代码来落地,并且组织越大这个落地的难度越大。不单单是系统架构,每个解决方案每个项目也由自己的架构,如分层、设计模式等。如果每一块砖瓦不够坚固,那么整个系统还是会由崩塌的风险。所谓“千里之堤,溃于蚁穴”。

  误区2——架构师确定了架构蓝图之后任务就结束了:架构不是“空中楼阁”,最终还是要落地的,但是架构师完全不去深入到第一线怎么知道“地”在哪?怎么才能落的稳稳当当。

  误区3——不做出完美的架构设计不开工:世上没有最好架构,只有最合适的架构。我们需要的不是一下子造出一辆汽车,而是从单轮车 --> 自行车 --> 摩托车,最后再到汽车。想象一下2年后才能造出的产品,当初市场还存在吗?

五、结语

架构之路任重而道远。程序设计和架构设计是互通的,每个人都可以从设计好一个程序往设计好一个系统架构前进。如果现在还无从下手的,我推荐大家可以从领域驱动设计这个概念入手,这是由业务为导向的设计方式,可以对培养设计出落地的架构有很大的帮助。本人目前也正巧在写如何一步一步用DDD设计一个电商网站系列,希望可以给大家一些思路和启发。最后引用“俞军”一句名言,我们作为架构师要有“怀疑精神:自我迭代”的心。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏BestSDK

VR画面再完美,也少不了这款全景语音SDK助力

时代拓灵的全景声解决方案正是从低成本、易使用切入。硬件方面,时代拓灵主打面向 B 端的全景声录制设备 Twirling720,其最大特点是一体化程度高、便携易用...

3574
来自专栏大数据挖掘DT机器学习

大数据处理技术,特点及作用

要理解大数据这一概念,首先要从”大”入手,”大”是指数据规模,大数据一般指在10TB(1TB=1024GB)规模以上的数据量。大数据同过去的海量数据有所区别...

4517
来自专栏携程技术中心

干货 | 数据分析在携程产品设计中的应用

作者简介 林传毅,携程旅行网资深交互设计,负责酒店产品和客栈通(www.kztpms.com)的整体设计。先后毕业于复旦大学计算机系和香港大学商学院,曾就职解放...

2897
来自专栏腾讯大数据的专栏

腾讯移动分析产品测评大赛启动,丰厚大奖等你来!

29412
来自专栏DevOps时代的专栏

重磅发布!2017年度 DevOps 现状调查报告中文完整版!

2017年度DevOps现状调查报告中文翻译完整版可以下载了,文末有链接! 满满50多页,全部翻译成中文了!DevOps时代和高效运维社区第一时间组织国内知名公...

8595
来自专栏Python绿色通道

项目实战第二季

最近公众号有一段时间没有更新了,主要是工作上有点忙,同时也在准备数据分析的课程,以及项目实战第二季的内容,所以有些耽搁,但我是真的爱你们,废话不说进入正题!

1042

实时数据分析:未来之路

即使商业世界仍在处理如何充分利用来自各种不同客户接触点的业务以及交易和相互作用产生的大量数据的问题,我们也看到了另一方面数据的曙光 ,即实时流数据 ,如果不是更...

4377
来自专栏ThoughtWorks

不做代码审查又怎样?| TW洞见

今日洞见 文章作者/配图来自ThoughtWorks:王健。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站...

3367
来自专栏互联网杂技

专业科班的答案!一个完整的交互设计流程是怎样的?

编者按:初学交互设计的新人,因为没有做过任何的设计项目,所以不知道整个交互设计师的工作流程会有哪些内容,今天这篇文章请了专业科班出身的设计师来科普他们在实际项目...

39012
来自专栏老九学堂

面试须知的五大要点,也许能让你快人一步

1. 说得太少 尤其是那些开放式的问题,如“请介绍下你自己”或“请讲一下你曾经解决过的复杂问题”。面试官会通过你对这些技术和非技术问题的回答来评估你的激情。他们...

35411

扫码关注云+社区

领取腾讯云代金券