灵动的水 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-北京-gome zk解决什么问题的？
灵动的水 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系统的解决方案。但不代表必须要有多年的开发经验，可能是与现阶段的教育水平有关的，将来可能会有像建筑 设计师那样直接培养，他不用从“工地”上开始培养。……但这样是否就断了开发人员往架构师发展的路径了（或者优势不明显了），这个扯远了，不讨论吧！
