高手问答第 152 期 — 聊聊架构,洞见架构之道

局长 发布于 2017/05/08 18:43
阅读 7K+
收藏 22

OSCHINA 本期高手问答(2017 年 5 月 9 日 — 5 月 15 日)我们请来了@kevinarch (王概凯)为大家解答关于架构的问题。

王概凯,资深架构师,《聊聊架构》一书作者。

提起“架构”,大部分开发者都会觉得十分高大上、遥不可及。他们或许会认为这对于开发没有实质性的帮助。但其实不然,站在更高的维度上看待和思考问题,能带来不一样的思路和启发。这对于开发恰恰是十分重要的,毕竟开发就是思考的结晶。

再看现在的技术圈子,关于架构的讨论和分享很多,不少公司都乐意分享自己的架构实践、架构图,也会有很多同行互相参考、借鉴。但事实上,因为公司的业务、规模、发展情况都不一样,所以很多时候会发现很难实现真正意义上的借鉴。究其根本,是因为大家缺少对架构的本质理念的思考。没能透过众多的架构相关分享看清架构的本质,何以真正解决问题?

本期高手问答欢迎大家围绕架构这个话题,一起探讨架构的相关问题。

为了鼓励踊跃提问,@局长 会在问答结束后从提问者中抽取 名幸运会员赠予《聊聊架构》一书。

本书通过大量的实例,一步一步揭示出架构背后的原理,以及架构在软件行业的发展,并通过企业实例来展示软件架构的实际应用,向读者揭示最本质的架构之道。

购买方式:请扫描下方二维码进行购买

扫描二维码可查看书籍的目录和简单介绍。

OSChina 高手问答一贯的风格,不欢迎任何与主题无关的讨论和喷子。

下面欢迎大家就架构相关的问题向@kevinarch 提问,请直接回帖提问。

加载中
0
局长
局长

OSC 高手问答第 152 期 — 聊聊架构,洞见架构之道(公布中奖名单)

@moishalo  @xiaoaiwhc1  @moshengren  @Yashin  @Ryan-瑞恩

恭喜以上五位朋友获得《聊聊架构》图书一本

请私信@局长 告知快递信息(格式:姓名+电话+地址)

3
m
moshengren

 用面向对象的思想来说,架构应该就是把各种对象整合起来,让各对象的功能更单一,之间依赖更小的一个框架。架构的目的,说白了就是为了积累。一个在自己行业里经营了很多年的公司,如果有一个好的架构,那么就可以很快的构建出一套这个行业所需要的业务系统出来,而且很稳定,问题很少,因为所有的对象或模块,都已经经历了长久的提炼,而如果没有好的架构,那构建出来的系统就像是一次性用品,而且这样的公司,哪怕经营的再久,积累的最多也就是用户,一有新的业务需求,全部又要从无到有的做。

m
moshengren
回复 @kevinarch : 同意,架构不是一种产品,而应该是一种能力,没有万能的架构,只有万能的架构师
m
moshengren
回复 @kevinarch : 谢谢老师回复
k
kevinarch
稍微再补充一下,所谓的积累,就是要知道这些对象是怎么拆出来的,为什么是这样拆出来才对。只知道一个最后结果,也仅仅是一个事后诸葛亮,不能成为自己的东西。这个拆的过程和理由非常重要,实际上就是行业发展的历史,犯过很多的错才能得到的
k
kevinarch
您说的很对,积累很重要。稍微补充一下,这个积累实际上是业务的积累。一个所有人都没做过的业务,是无从谈积累的。可是软件行业所服务的业务,都是已经积累了比较久的时间的,已经有了良好的架构。软件行业业务本身也已经有了几十年的积累。这些积累都要落地在架构师的身上
0
青苗
青苗

@kevinarch  沙发先坐

0
xpbob
xpbob

@kevinarch   我对架构的理解就是,去选取一个合适的方案以及合适的技术做完成一个项目,中间包括预计后期的扩展性方案的一个风险评估的方案,不知道是不是接近实际的架构呢

k
kevinarch
回复较长,无法在评论中一一回答,请参见单独的回帖
0
李三石
李三石

@kevinarch 架构 技术 需求 之间的关系能聊聊吗?另外对于架构设计来说现在的需求和未来的方向那个更重要?

k
kevinarch
您想问的合并起来是不是就是:新需求来了,架构和技术如何快速满足,并且尽量不影响未来的工作? 我想这个问题实际上反映的还是对业务的不熟悉。解决这个问题,就要去深挖业务的需求,找到需求真正的主体,这个主体绝不是产品经理。理解了核心业务,架构就出来了,用什么技术也就不成问题了,未来也很清楚。甚至识别出来很多需求可能根本不用做
0
k
kevinarch

引用来自“xpbob”的评论

@kevinarch   我对架构的理解就是,去选取一个合适的方案以及合适的技术做完成一个项目,中间包括预计后期的扩展性方案的一个风险评估的方案,不知道是不是接近实际的架构呢

说到架构就离不开业务,必须要结合业务来说。不同的业务有不同的架构。比如建筑有架构,社会有架构等等等等。放到软件领域,就要结合软件的业务,以及软件所表达的目标业务来说。比如电商的架构,就包含了售卖型企业本身的架构,以及软件行业本身的架构。而对于架构而言,就在于要保证业务的增长。而保证增长就要通过并行的方式来达成,因为每个人的精力有限,通过合理的分工,可以通过增加更多的人来达到增长,这就形成了组织架构。组织架构是人类架构的核心,因为人类的业务都是由人来推动的。软件也不例外,需要通过组织不同角色的人来完成软件的生命周期,所形成的不同软件也组织成了一个架构。因此架构是业务本身特性的一个延伸,不理解业务是无法做好架构的。

您说的合适的方案以及合适的技术自然是需要的,可是如何算合适?判断标准是什么?这个才是关键。架构不是设计出来的,是隐藏在业务本身的特性里的,理解了业务,架构就自然清楚了。您说的扩展性实际上就是应对业务的增长,这是架构的核心内容,也是隐藏在业务本身的特性里的。

0
Ryan-瑞恩
Ryan-瑞恩

@kevinarch 说道架构,我们一般都会说业务,业务决定着架构,架构影响着性能。有人说,架构要预留扩展,而有人又说,不要过度设计,请我,在这方面,你是如何平衡的???对于大数据架构方面,请问,你有什么好的思路或原则?谢谢分享!

k
kevinarch
回复 @Ryan-瑞恩 : 如果IO本身的业务不够熟悉,对IO的核心生命周期没有深刻的理解,这些分拆自然是不可能的,也不可能产生新的技术。
k
kevinarch
回复 @Ryan-瑞恩 : 在同步的业务过程中把非核心的业务步骤分拆出去交给别人来执行,自己专注于核心业务部分,所形成的就是架构。分拆需要技术的支持才能达成
k
kevinarch
回复 @Ryan-瑞恩 : 奇技淫巧是技术的事情了,架构非关技术,却又离不开技术。技术的进步可以让新的架构分拆成为可能,二者是相生的关系。在软件中例子很多。比如所谓的同步IO,同一个线程先接收到数据然后才能继续处理请求。把数据接收和处理分拆开后,接收数据的线程和处理数据的线程分离,性能提升了,扩展了,形成所谓的异步技术,同时形成新的架构
Ryan-瑞恩
Ryan-瑞恩
回复 @kevinarch : 在架构方面,你经历过的,有什么奇技淫巧的案例,,求分享一些!非常感谢。
k
kevinarch
是的,业务决定架构。谈架构不说业务是没有意义的,离开业务说性能也是没有意义的,离开业务说扩展也是没有意义的,离开业务说大数据也是没有意义的。 要说业务首先就要识别出来所面对的业务是什么。对于大数据所面对的业务是什么?软件本身访问的大数据和订单的大数据是两种不同的业务。业务的主体识别清楚了业务就清楚了,这就是大的思路和原则
0
青蛙是你

@kevinarch 我要拜你为师,求辞书. ......师傅,请受徒儿一拜 ~~~

Ryan-瑞恩
Ryan-瑞恩
徒儿,去给师傅弄两niu 来。。。。
0
熊大信了熊二的话
熊大信了熊二的话

@kevinarch    架构不是分为业务架构 数据架构等等  该书偏向那个

架构的最终是管理还是技术

k
kevinarch
回复 @熊大信了熊二的话 : 用什么进行拆分不是问题,为什么拆分才是问题。解决谁的问题?能回答这个问题,心里就有谱了
熊大信了熊二的话
熊大信了熊二的话
回复 @kevinarch : 非常感谢您的解惑, 目前公司碰到一个小问题 希望能给点建议, 发展型公司。现在公司多个项目后台人员/权限/前台用户这块是一致的, 如果我是一个架构,是目前就考虑dubbo进行拆分,还是先hessian处理,从人员,技术还有后期的考虑?能否给点建议 谢谢
k
kevinarch
最后一个问题前面没看清楚,补充回答一下。架构最终是管理还是技术?这是一个好问题。技术已经回答过了。架构对于管理来说是值得思考的。先要回答:什么是管理?搞清楚了这个概念,架构和管理的关系就可以自行展开分析了
k
kevinarch
这本书首先对架构做了一个总体的探讨,然后探讨架构在软件中的扩展,最后是探讨在企业中的应用。 架构都是业务架构,业务不同架构也又差异。数据架构也是针对数据业务本身的架构,也是业务架构。当然架构本身也有架构,形成更细分的架构,因为架构本身也是一个独特的业务。 该书只讨论架构,会涉及架构与技术的关联,毕竟无法单独讨论架构。
0
小杨阿哥哥
小杨阿哥哥

@kevinarch 现在知道架构会随着业务的发展不断的变化,只是还是需要大神指点,一直对与分布式事务还有数据库集群不太熟悉,可能大公司内部都有自己好的框架吧。

k
kevinarch
事务是绕不开的话题。先别被数据库给搞晕了。先思考什么是事务?什么是分布式事务?业务是什么?解决的是谁的问题?解决的是什么问题?搞清了这些问题,自己就有答案了。
Ryan-瑞恩
Ryan-瑞恩
分布式事务,,2PC,3PC,,,数据库集群,分横向和纵向!最终落地主要还是由业务和数据量决定!
返回顶部
顶部