查看: 106|回复: 0

架构随聊

[复制链接]

该用户从未签到

发表于 2019-11-3 14:52:58 | 显示全部楼层 |阅读模式
阅读目次



一、架构的界说

  所谓一千个架构师中有一千种“最好的架构”模式。
  “架构”是我们这行业种一个很常见的词,表明其必然也是经历了很长的岁月打磨所形成的一个词。架构的这个词出现的意义是什么?为了解决什么问题?只有把这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设计一个电商网站系列,希望可以给各人一些思路和启发。最后引用“俞军”一句名言,我们作为架构师要有“怀疑精力:自我迭代”的心。


作者Zachary
出处:https://zacharyfan.com/archives/210.html

关于作者:张帆(Zachary,个人微信号:Zachary-ZF)。坚持用心打磨每一篇高质量原创。欢迎扫描右侧的二维码~。
定期发表原创内容:架构设计丨分布式系统丨产品丨运营丨一些思考。

如果你是初级程序员,想提升但不知道如何下手。又大概做程序员多年,陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」,回复「技术」,送你一份我恒久收集和整理的头脑导图。

如果你是运营,面对不停变化的市场束手无策。又大概想了解主流的运营策略,以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」,回复「运营」,送你一份我恒久收集和整理的头脑导图。

天涯海角也要找到Ni:架构随聊

中发现Ni: 架构随聊
中发现Ni: 架构随聊
中发现Ni: 架构随聊
中发现Ni: 架构随聊
中发现Ni: 架构随聊
中发现Ni: 架构随聊
相关技术服务需求,请联系管理员和客服QQ:2753533861或QQ:619920289
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

帖子推荐:
客服咨询

QQ:2753533861

服务时间 9:00-22:00

快速回复 返回顶部 返回列表