欢迎您光临本小站。希望您在这里可以找到自己想要的信息。。。

架构漫谈讨论

架构&设计模式 water 2689℃ 0评论

灵动的水 11:47
我想问一下,架构和框架的区别和关系,架构师和框架的关系,框架在架构师眼里扮演的角色,现在常听说什么什么系统框架都搭建好了,怎么理解

灵动的水 11:48
这两天在看架构漫谈系列,提出的疑惑。

灵动的水 11:49
现在常听到,什么什么框架都是现成的

Kevin 11:51
架构的连接点上,有很多共同需要处理的东西,主要是起连接作用

灵动的水 11:51
连接点就是框架?

Kevin 11:53
可以这么认为,把一个成熟的分拆模式化,并提供一定的定制化的,叫框架

Kevin 11:54
框架就是一个domain的处理打包重用的结果

Kevin 11:55
本身是一个架构的实现

灵动的水 11:55
框架是架构里面的一部分,架构里面问题的通用解决方案?

Kevin 11:56
首先,这是两个东西

Kevin 11:56
框架是某种架构的一个实现

Kevin 11:57
比如mvc是一种架构,spring mvc 是一种框架

灵动的水 11:57
嗯嗯,有点明白了

Kevin 11:58
架构定义好了分拆,职责

灵动的水 11:59
互相包含么?,那web项目是不是一个架构,它里面包含Spring McCoy

灵动的水 11:59
Mvc

Kevin 11:59
框架把重用的部分写好了,使用者按照约定去对接就好了

Kevin 12:00
如果web项目是一个订单系统,可给别人重用,那么本身就是一个框架

Kevin 12:01
作为框架本身,他有自己的架构

灵动的水 12:01
奥,明白了

Kevin 12:01
用某个框架,就意味着要遵守这个框架本身的架构约定

灵动的水 12:02
那架构师和框架之间的关系呢?

Kevin 12:02
架构是灵魂,框架是四肢

Kevin 12:03
合体才好

灵动的水 12:03
系统架构师,是不是需要了解各种热门的框架

灵动的水 12:03
各种好的框架都是好的架构师设计的?

Kevin 12:03
先要了解架构,才有资格去了解框架

Kevin 12:03
当然了

灵动的水 12:05
现在感觉的架构师,都是能够运用各种前沿的框架

Kevin 12:05
不了解mvc, 学得好spring mvc?

灵动的水 12:06
嗯嗯,是的

Kevin 12:06
别管别人,做好自己

灵动的水 12:07
嗯嗯,好的,先吃饭了,回来思考

灵动的水 12:09
谢谢

大老李 12:09
嗯,

大老李 12:10
mvc是架构,spring mvc是框架,框架就是架构的具体化,我可以这么理解么?

Kevin 12:10
可以这么理解

Kevin 12:12
学框架时,总要先学习一些核心概念,这些概念实际就是架构的核心分拆,核心domain

大老李 12:14
[强]

Kevin 12:15
重点是这些核心概念和分拆,都来自现实生活,千万别忘了。软件没创造出来过什么东西

Kevin 12:16
不能凭空分拆

Kevin 12:16
否则没人能理解

maoC 12:24
架构是思想,框架是"特定"的规则

maoC 12:25
当然,刚才有个朋友也说到了,框架本身存在架构,是对的

maoC 12:26
架构无处不在,就算是再烂再普通,也是一个架构,因为再烂的思想再普通的思想也是思想嘛

金子塔法老 12:26
[强]

Kevin 12:32
框架是某种架构的实现。特定的规则,就是这个架构

灵动的水 12:40
那系统架构师,在搭建系统架构的时候,会考虑到技术选型,架构选型的

灵动的水 12:40
框架选型

 

灵动的水 12:41
好的架构师必须对各种好的框架有所了解啊,厉害的自己写框架

maoC 12:41
记住一点,业务驱动架构,技术是架构的支撑

maoC 12:42
不能直接抛弃业务,就进入到什么架构,框架

灵动的水 12:42
嗯嗯,理解,业务很重要,业务驱动

灵动的水 12:43
但是,现在面试的时候,考察的大部分还是技术

灵动的水 12:44
找工作的时候,有好多都是跳业务领域的

灵动的水 12:45
架构师是业务专家,同时也应该是技术专家

Backkom 12:49
挑技术专家比较多,业务很多都自己人[悠闲]

灵动的水 12:50
对啊,这是现实,所以困扰

maoC 12:58
集业务与技术于一身的人大有人在,技术背景的人,在一个业务领域里从事久了,通过项目中需求获取的只言片语的积累,用心的去梳理业务的流程与规则,自然能成为业务专家啦

maoC 12:59
这个业务专家当然不是去跑业务,而是能听得懂对面那位业务专家在说什么哟

灵动的水 13:00
技术是解决业务问题而产生的。一些业务问题是共性的,一些技术框架就是为了解决这些共有业务而存在的

maoC 13:00
甚至,在各种项目中成长的”业务“专家,往往会比在同一个机构里的业务专有更了解业务

灵动的水 13:01
那架构师也必须有了这些技术,以后碰到这些业务才能解决

maoC 13:04
架构漫淡里有一章是介绍技术与业务的关系的,我没有认真去看。water可以多读几次吧

maoC 13:06
对于技术与业务的关系,我以前也有疑问,到底是先有技术呢,还是先有业务呢?到底是技术推动业务呢,还是业务推动技术呢?见仁见智的问题。反正我觉得今时今日,两者相辅相成吧

灵动的水 13:07
可能视角不一样,有了技术的人就重视业务和管理类的,技术层次不深的他更需要技术来提供自信

maoC 13:12
所有这些问题,每个人都会经历到,不了解不清楚时,只是因为当时”身在此山中“,等”更上一层楼“时就想通了。有个笑话就是,30岁之前不知道自己是个傻B,30岁过后就不在乎自己是个傻B了。呵呵

灵动的水 13:14
漫谈架构就是给架构师提醒,不要只重视技术,不要老以技术眼光看问题,学会从问题根源用技术解决问题。

灵动的水 13:15
嗯嗯,视角和经历不同。

灵动的水 13:17
好多架构师现在干的事是,封装前沿框架提供一些服务,一些繁琐业务交给工程师去弄

灵动的水 13:18
他们解决现在互联网行业面临的通用困难问题业务

灵动的水 13:20
这是我现在对架构师的印象,熟悉前沿技术框架的一批人

Backkom 13:22
不少搞技术的兄弟都是说,业务你们搞就行了,我负责实现就行,是不是现状

mickey 13:22
只要熟悉业务,才能有的放矢,否则都是炫技。

田牧 13:23
架构师应该了解业务,这样才能有的放矢,做出相应的架构

灵动的水 13:24
好多架构师,介绍自己的时候不都是说,我参与bat哪些系统项目架构框架的搭建么

灵动的水 13:32
系统架构师是一个最终确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实
现”。因此他/她应该是特定的开发平台、语言、工具的大师,对常见应用场景能马上给出最恰当的解决方案,同时要对所属的开发团队有足够的了解,能够评估自
己的团队实现特定的功能需求需要的代价。
系统架构师负责设计系统整体架构,从需求到设计的每个细节都要考虑到,把握整个项目,使设计的项目尽量效率高,开发容易,维护方便,升级简单等。

Kevin 13:43
@maoC很不错

maoC 13:44
@Kevin[握手]

Kevin 13:47
业务和技术的关系:技术服务于业务,技术enable业务。业务给技术提供场景,给技术提供平台,提供血液

Kevin 13:47
提供问题

Kevin 13:47
提供动力

灵动的水 13:50
嗯嗯,是的。。我再多看几遍文章。。

灵动的水 13:52
业务是核心,技术是手段。。

灵动的水 14:00

设计架构的时候,是先梳理业务梳理问题,然后再去看看能用什么技术去解决。。

灵动的水 14:02
但是一个架构师,最起码得有技术支撑吧,他应该是先是技术专家,然后进入一个行业,通过和业务专家学习,梳理业务,然后设计出来架构吧

灵动的水 14:03
那成为架构师,是先技术积累,还是先业务积累?

陶邦仁 14:04
以业务为目标,技术为手段,解决业务的同时,会有技术的积累、成长。

徐智 14:05
我提出“领域信息系统”的概念是否可行?

Kevin 14:05
先假装什么技术都会,克服技术恐惧

灵动的水 14:05
领域驱动可以,你没技术积累。。业务能开展?

Kevin 14:06
把技术看太难,就出不来了

Kevin 14:07
别人刚毕业的都会,还比他们差?

陶邦仁 14:08
有时没有技术,架构也会存在、业务也会存在、技术就只是一个工具而已 高效的手段啊、

Kevin 14:09
@陶邦仁-北京-千丁对了,明白了问题,自己就能发明技术

灵动的水 14:09
火其实就是一个业务目标,要解决的是人类自己的问题
====火能不能看成它一直存在着,然后人类发现了它的作用(烤暖和做饭),然后学会怎么更好的利用它?

Kevin 14:09
更何况使用技术

Kevin 14:10
火的基本功能,发热发光

灵动的水 14:10
设计系统架构是先分析业务,再找技术

Kevin 14:11
都是对付自然的利器

灵动的水 14:11
但作为架构师,我感觉你手中得有工具,你才能干活。。

地球村 14:11
我觉得还是根据具体业务,思考,梳理拿捏决定应该用什么技术最适合。真正用时还是业务提供动力

灵动的水 14:11
手里得有技术。。

Kevin 14:11
@water-北京-gome目的不是为了找技术。是为了成本更低的解决问题

流泉飞石 14:12
架构师知识面一定要广,才能在合适的地方,用合适的技术解决业务问题

灵动的水 14:12
没有金刚钻别揽瓷器活

Kevin 14:12
但首先得能解决问题

流泉飞石 14:12
还有合适的时候

灵动的水 14:13
设计架构,解决问题,肯定是问题先存在。。然后找对应的技术去解决。。没有技术自己创造,已经存在的技术然后运用。。

Kevin 14:13
知识和技术是否要广,是一个伪命题,刚开始都不可能广

灵动的水 14:14
但成为架构师,必须先从技术入门。。

Kevin 14:14
问题解决的越多,就越广

Kevin 14:15
@water-北京-gome恰恰相反,先能识别出问题,才可能成为架构师

流泉飞石 14:15
技术专家和架构师还是有区别的

灵动的水 14:15
那架构师一定不一定是技术专家呢?

Kevin 14:15
技术多了,就变成茴字有多少种写法了,这是谁,知道吗?

流泉飞石 14:16
架构师首先要对业务敏感,对技术能够解决的问题敏感,通过分析比较,找到合适的技术

灵动的水 14:17
程序员,不都是先学技术,然后再接触业务么?架构师不是从程序员技术专家成长起来的么?

Kevin 14:17
没有技术,创造技术也要解决问题,才是架构师

流泉飞石 14:17
分析比较的过程,就是一个沉淀技术和知识的过程。另外,通过实际解决问题,技术能够很快成长

Kevin 14:18
@water-北京-gome没谁这么规定。建筑架构师,搬砖吗?

灵动的水 14:18
你们所谓的架构师,是已经是架构师了。。。。。

陶邦仁 14:18
可能现在来看有很多技术存在,Java、c、等等等,但这些技术产生的初衷就是为了解决获取更多利益的问题而产生的。比如可以做更搞笑的计算,简化繁杂的工作等、、、

陶邦仁 14:18
每一个人本身就是一个架构师。

Kevin 14:18
搬砖历害,一定能成为架构师?

helloworld 14:19
人人都是架构师

Kevin 14:19
@陶邦仁-北京-千丁对了

陶邦仁 14:19
但是卓越高效的架构师却少之又少、、、

Kevin 14:20
当大家思考自己的书怎么分类摆放的时间,就是在做架构思考

Kevin 14:20
思考的结果,就是一个架构决策

Kevin 14:21
所以我们经常讲practice

灵动的水 14:21
那身边的架构师有多少不是从技术出身的?

流泉飞石 14:22
架构伴随很多决策

Kevin 14:22
大部分人往往都没意识到是在做架构

helloworld 14:22
这个没有吧

Kevin 14:23
有意识的,有训练的思考,才是严格意义的架构师。但每个人都有这个潜质

灵动的水 14:23
业务产生技术,可以那么说,技术服务业务。。

helloworld 14:24
在还是helloworld水平的时候,就要考虑“架构”。[酷]

Kevin 14:24
误解太多了

灵动的水 14:24
阴阳两极吧。。。没有谁先谁后

灵动的水 14:25
就跟您文章中说的,采用弓弦来提升木棍转动

灵动的水 14:25
这个用弓弦提升木棍转动。。它一直存在着

Kevin 14:25
可以认为"相生",一定是业务需要,才会有技术传承下来

灵动的水 14:26
他能够服务于加快取火这个业务。。

三目草 14:26
没有技术作为底子设计的架构系统会一直处于重构中

Kevin 14:26
没有快速转动的需要了,它也会消失

陶邦仁 14:27
大家可以先看看@Kevin 的架构漫谈系列 站在巨人的肩膀可以看的更远更深。当然了 能带着自己的见解看就更好了。

灵动的水 14:27
所以有些业务产生了技术,但是它能服务于其他的业务。。

陶邦仁 14:28
弓弦一直存在的” 可能是存在,但不一定是解决取火转速高效问题的。

灵动的水 14:28
产生之后的技术又服务于其他业务。。这是你想不到的。。

Kevin 14:28
快速转动技术可服务的更为广范,会用到其他有同样问题的地方

灵动的水 14:29
对啊。。如果取火的人不知道这个技术。。那他还一直用手呢。。。

Kevin 14:29
某个领域需要这个技术的人,不知道这个技术,但一定会发明出来

灵动的水 14:29
架构师现在重要的不是发明技术,现在就有很多技术一直存在着

Kevin 14:30
可能就不一定是弓弦了

陶邦仁 14:30
或许弓弦在取火场景中 可能就不是叫“弓弦”的名字了

Kevin 14:30
@water-北京-gome不一定现有的技术都合适

Kevin 14:31
所以要看成本,要看组合的人的水平

陶邦仁 14:31
最好是从第1篇开始啊

Kevin 14:31
这个人不一定是每个技术的专家,会用就可以

Kevin 14:32
就好比我们都造不好锤子,但用还是可以的

陶邦仁 14:33
对的

灵动的水 14:33
是的。。现在一些技术不用你去创造了。。

Kevin 14:33
组合好技术,不就是日常生活中时时都在锻炼的吗?

灵动的水 14:34
互联网的架构师。。。需要掌握好这些技术。。等进入一个领域后。。碰到然后能想起这个技术就行

Kevin 14:34
边走路边用手机,边吃零食

Kevin 14:34
这就是生活的智慧,就体现在架构中

灵动的水 14:35
业务和技术就是阴阳两极。。

灵动的水 14:35
作为架构师,互联网行业一些核心业务是共有的。。技术是通用的

灵动的水 14:36
国内框架不都是借鉴国外的么??

陶邦仁 14:36
业务和技术不能相提并论 没有了业务的技术等于0 但没有了技术的业务照样可以玩的转

灵动的水 14:37
有多少技术是自己创造的?

Kevin 14:37
有疑问就非常好,这样才能思考,就有收获。这个世界是没有对错的

Kevin 14:38
@water-北京-gome没有技术,业务照样玩,成本高一点而已

Kevin 14:39
只有技术降低了业务的成本,业务才会buy in

Kevin 14:39
最早业务人员本身就会技术

陶邦仁 14:40
既然拿来就可以满足业务 为何要自己创造 只有不能满足业务了,遇到问题才会创造而已。

Kevin 14:40
软件行业特殊的地方就在这,业务都不懂软件

灵动的水 14:40
那我问一下,怎样成为架构师啊?

陶邦仁 14:41
没有技术只是成本高 效率低而已 但业务依旧存在 技术可能就over了 或者迭代更新。

Kevin 14:41
去思考业务问题才行

陶邦仁 14:41
看架构漫谈系列啊

灵动的水 14:42
按文章是先懂业务。。学会思考问题。分析问题。。

陶邦仁 14:43
是的 先从思维方式上转换。

灵动的水 14:43
那大部分架构师都是从高级程序员转型过来的吧?有多少产品经理??

Kevin 14:43
业务每过来一个需求,都是问题,从这里入手

陶邦仁 14:44
业务每过来一个需求,都是问题,从这里入手 [强]

Kevin 14:44
每个人不一样,没有通用的模式,条条大路通罗马

地球村 14:44
纵观社会发展历史,生产力发展,人类都是为了提高效率,而发展的技术,软件也是

地球村 14:45
软件是人类发展史上一个过场

Kevin 14:46
如果业务说怎么干就怎么干了,也没有思考解决谁的问题,什么问题,那就还离架构师很远

灵动的水 14:46
有多少是在创造技术的啊??

灵动的水 14:47
我是说系列文章,,只是给架构师提供了新的角度看问题。。。从产品和管理角度。。

灵动的水 14:47
但前提是这个架构师已经有了一定的技术积累才能有这些思考

Kevin 14:47
@water-北京-gome您的入手点还是技术,放不下

Kevin 14:47
慢慢来

三目草 14:49
要看公司和业务特点吧,互联网企业还是比较强调技术的,如果只是外包无所谓了

Kevin 14:52
活得好的互联网公司,都是很强的业务。只强调技术的,不可能活得长

Kevin 14:53
公司的本质,都要获取利润养活大家。谁的成本低,活得就更好

Kevin 14:53
这是技术的动力

三目草 14:54
而且如果不懂技术底下人不一定听你的

Kevin 14:55
不是的,技术再好,解决不了业务问题,谁听他的?

灵动的水 14:55
条条大陆通罗马吧。。
你碰到问题了,然后去找相应的技术解决,
你会了这项技术,碰到其他问题,可能也能用现有技术解决。。

Kevin 14:55
只要能解决问题,他的话大家一定都听

Kevin 14:56
马云不懂技术,大家都听他的

三目草 14:56
那不一样

灵动的水 14:57
马云是架构师么??

三目草 14:57
那是boss

灵动的水 14:57
马云是公司架构师,管理者

Kevin 14:57
设计公司的组织架构,算架构师吗?

Kevin 14:58
这是架构师中最牛的

三目草 14:58
所以要分业务架构和技术架构

Kevin 14:58
漫谈里也提到了,组织架构才是架构的核心

Kevin 14:59
这里不展开了

Kevin 14:59
大家继续讨论

灵动的水 14:59
举例子说吧。。zookeeper,你只有先了解了。。你 才知道往哪用

灵动的水 15:00
也有碰到问题了。。然后去了解这个技术的。。那作为架构师那个更合格些??

三目草 15:02
技术为业务服务是没错,但技术的发展能为业务提供更好的体验,如果一个系统天天崩溃,用户也会失去

Kevin 15:02
@water-北京-gomezk解决什么问题的?

灵动的水 15:03
配置维护、域名服务、分布式同步、组服务

Kevin 15:03
没有zk的时间,大怎么活过来的?

Kevin 15:03
@water-北京-gome这么理解,一定用错

麻豆 15:03
我也觉得没必要掉进一个技术细节和技术框架里的

麻豆 15:04
已解决问题为先

灵动的水 15:35
我仔细想了下,现在的架构师能够切实分析出根本问题比较重要,然后找出合适的技术解决。但现在的 工程师在公司接触的业务面比较少,碰到的问题也有限,分析问题能力有限。所以只能多学各种技术框架,克服内心的技术恐惧吧。怕自己碰到问题无法解决。碰到 问题就会往自己会的技术上靠。(所以先有基本的架构师素养,然后自然而然的积累技术,沉淀技术),才能成为合格的架构师吧,掌握各种技术的只能称为技术专 家吧

阿涛 15:42
架构师应该分业务架构师和技术架构师吧

灵动的水 15:45
就像例子中的那个切土豆的人。。。

灵动的水 15:45
就算他技术再好。。他也当不了架构师

陶子 17:42
[疯狂的架构:国内六大著名科技公司组织结构图一览 : http://mp.weixin.qq.com/s?__biz=MzIxNjA4NjE5MQ==&mid=401670472&idx=1&sn=3b5eb25a9d7fd581d94b73fbdf19a2c3&scene=1&srcid=0308CU92ymBM5JBDoVpDf0lg#rd]

云飞 18:32
其实没必要把架构、技术什么搞那么复杂。一切都是为了解决问题。对于自我来说,一种是被动问题(别人找你),一种是自我发现问题。架构是思考如何更好解决问题的过程,技术是解决问题的手段。

云飞 18:36
一直保持发现问题的状态,技术自然而然就好了。然后思考解决问题的能力也会提高。良性循环。

云飞 18:41
kevin和群里的其他朋友之前都提过这方面的。一般善于思考和学习的人,多少都会有这方面的感悟[呲牙]

Kevin 18:50
自己技术好了,然后大谈技术去了,这就有点忘本了,技术就很难进步了

云飞 18:54
确实是啊,只有不停想各种为什么,才能进步。而且不仅限于技术。炒菜啊、和人沟通啊等等,任何事情均适用。

Kevin 19:21
没错,做什么事都一样,没明白问题前,不要轻易出方案

Kevin 21:12
代码有问题的可能性大。下次hang的时间做个dump

Kevin 21:16
Thread dump. Java的?

Kevin 21:27
数据库层面监控报警

Kevin 21:28
Session执行时间过长就要报警

云飞 21:37
@广州-hoping发生sql卡住的时候用show processlist。看看是不是有sql执行的时间很长。

云飞 21:40
数据量几万就卡,查查是不是数据库没做优化?用的默认配置?如果是没有化,看引擎是innodb还是myisam。根据不同引擎做相关优化

云飞 21:41
show processlist和slow query可以确定哪些sql慢。看my.cnf看是不是没有优化。

云飞 21:47
几万条记录就慢,即使是多表联合也不应该。如果真是sql执行慢。多半是没有对mysql配置优化,或者优化不正确。

—————  2016-3-9  —————

子弹的微波 04:03
技术出身可以发展成为好的架构师,但并不是人人都能成为好的架构师,是需要条件的。没有做过技术或多年技术的不见得就不能成为好的架构师(这里的架构师特指采用IT技术解决问题的架构师),前提是要对IT技术的特性敏感。

子弹的微波 04:09
说到底,好的架构师就是能够快速理解业务需求,找到问题的根结点,能在业务上梳理(或协助其梳理)使其更为优化,并且能找到在当下相对比较恰当可行的解决方案和实施路径的人(主要是技术方面,但甚至是不局限于技术)

子弹的微波 04:26
这方面我曾经有类似的经历,在N年前,所在公司还没有独立的清算部门,仅有几个岗位,我承担了 业务支撑系统的建设,其中清算是比较重要的部分,但当时没有成文的流程,很多东西都在每个工作人员自己头脑中也无法有条理地说出来,只会碰到问题就解决、 救火。正好当时有一个新来的员工(年纪大一些),便推动她说,系统要做的好用,先要有一个业务流程。由我负责起草,调研各岗位的工作(包括开发,运维,业 务处理,财务,市场等部门),梳理了成文的清算流程,设计了清算账户体系。系统顺利完成建设投产,后来一段时间后清算中心(部门)就成立了。我离职后聊起 来,这个业务支撑系统经历了几次升级,分拆,但核心的技术框架还是保留下来的

子弹的微波 04:27
刚才说的那位合作的同事后来成了清算中心的负责人

子弹的微波 04:28
不是说我的原因,她自己也是非常努力、一丝不苟的人,本来也是合适的人选

子弹的微波 04:39
啰嗦了点!我认为出现争论的原因是大多数时候,能做IT解决方案的架构师大多是从程序员成长而 来的,很少很少有不会编程的人也能做能落实到IT系统的解决方案。但不代表必须要有多年的开发经验,可能是与现阶段的教育水平有关的,将来可能会有像建筑 设计师那样直接培养,他不用从“工地”上开始培养。……但这样是否就断了开发人员往架构师发展的路径了(或者优势不明显了),这个扯远了,不讨论吧!

 

转载请注明:学时网 » 架构漫谈讨论

喜欢 (0)or分享 (0)

您必须 登录 才能发表评论!