架构师小组交流会：每期选一个时下最热门的技术话题进行实践经验
分享。
第二期：本篇文章是对于《来自滴滴、微博、魅族、唯品会、点评关于高可用架构的实践分享》的续接。
本期参与
嘉宾：滴滴技术负责人彭令鹏、魅族系统架构师何伟、唯品会应用架构负责人张广平、
新浪微博技术专家聂永、大众点评
交易平台技术负责人陈一方、七牛云首席架构师李道兵。
本文是对此次交流的整理，欢迎探讨。
第二轮：话题交流
主持人：大家觉得是需要有统一的技术架构部门，还是不需要有统一技术架构部门，各个业务部门自己独立往前发展？
唯品会张广平：如果我们有一个通用的基础架构，这样开发的学习成本比较低，学习一套，然后他可以持续的开发。那如果有多套框架的话，对于开发人员学习成本比较高，另外就是运维的成本。其实任何一个系统，它不是一个独立存在的东西。要
上线的话，还需要去做运维。简单举个
例子，我们开发了一套日志监控的框架，叫 Mercury，这个框架看起来技术和现有的一些比较流行的东西差不多。比如说用kafka，之类的等等的一系列作业。如果要运维，需要几百台机器才能这套系统玩得起来。如果我们各用各的框架，对于公司来说成本非常高，运维上去以后，每个框架都要去建一个运维团队去运维。刚开始是有这个问题，开发的东西很难推出去，刚开发了基础组件出一点点问题，然后就被无限地放大，就没人用了。我刚提到那个重构，我们自己去招聘一个团队，也是因为我们的CTO支持，给了我们一个团队，让我们去把这个重构做起来。当我们核心的服务一点一点接进去，
发现效果非常好，后面接入的团队越来越多。我们肯定也不能强行的去压，因为每个团队
他们都有KPI。我们当时是采取渐进的方式，一个一个模块去接。
滴滴彭令鹏：我还是倾向于业务架构跟着业务技术部一起走。因为无论是从百度的经验，还是在滴滴的感觉来讲，我们肯定是需要一些最基础的架构，像消息
队列、存储、计算这些，这个可以交给基础架构去做。但是做业务架构，我觉得还是要非常贴近业务，个人感觉，之前碰到过不少做基础架构的同学，他们做的架构其实和业务，比如说在延迟，或其他方面的一些需求，其实相差还是很大的，用起来不那么顺手。
魅族何伟：因为基础架构其实是大家都认可的，业务架构它一定是跟业务组的，因为业务的场景，比如原来技术架构开发MQ的框架，它的框架可能MQ正常，技术架构团队做出来的可能就是，消息的基本特征能发能接，业务要求是消息到达的时序，消息到达有延迟，它有时候就要求延迟，有时候这个消息必须在这个消息前面有持续的。像这种的话，架构团队是不了解的，还是要重新做。
滴滴彭令鹏：我觉得从整个团队来讲，可能在组建初期，这样做是可行的。但随着业务发展，团队肯定会去招一些新人，但新人其实他对业务会越来越不了解。而老人可能会逐渐偏向于做顶层设计，具体落地的时候，到最后新同学会实施的不好，那基本上满足不了业务需求。像百度网页搜索部和其他部门原来都是有自己的基础架构的，在2011年联合成立了一个专门的基础架构部，最开始业务部门和架构部门还愿意合作，但到2013年以后，基本上就不相往来了。
唯品会张广平：我们当时成立了一个架构评审委员会，我们在推的同时，也通过委员会去做一些强制要求，比如说每个项目我们都来做评审，如果你不用一些标准的东西，或者不按照一些
比较好的方法去解决，我们就不让他上线。
七牛云七道兵：如果有基础架构，其实最担心的事情，就是基础架构的东西卖不出去，就是业务部门不买基础架构部门的账。如果是各自做的话，就比较担心效率问题。更多是一些企业前期与后期的策略。
大众点评陈一方：技术架构其实是跟组织架构走的，或者是跟业务架构走的。基础架构其实和组织架构相关的。
第三轮：架构师能力提升的建议
主持人：这里有三个问题，大家挑一个来发表自己的观点。
1、很多架构师都是从
程序员转过来的，那么对于一个想成为架构师的程序员，你有什么好的建议?
2、不同架构师的在选型上会有不同的做法，有的偏保守，有的偏激进，你的观点是什么？为啥你会做这样的选择？
3、在做架构设计时，你最害怕什么情况？为什么？
滴滴彭令鹏：我选程序员转型。因为我做一线的工作挺多的。很重要的一点是，我们不能纯
写代码，还要留充足地时间去思考和抽象。因为我发现很多一线工程师他干了五六年，换了一家公司，或在一家公司呆了很久总是在写类似的业务代码。如果没有思考，我觉得他的能力还是上不去。第二是我们做一些事情要打破边界，很多程序员会觉得，这东西不属于我的，我不去接触，或者说这个东西c++的，我不熟，我也不管等等，这样知识面较窄。第三做了架构师以后，还是要贴近业务。而且对于一个程序员转过来的架构师，需要注意的是不要纯看技术，更重要的是贴近业务去落地。第四我们做一个东西，比如做服务治理，你战略上可以很大，有一个理想目标在那里，但是具体落地的时候，你每一项战术要做的非常细，才有可能做成。整个是一个螺旋迭代的过程。
魅族何伟：我刚才还是第二个问题，其实前面都很认同，一个是基础打好，然后就是学习一些业界架构方面的经验。我补充一点，做程序员，你要找机会来锻炼自己，而不是给你安排什么，你就去做什么，而是要多思考，敢于跟别人PK。第二个问题架构选型，我觉得没有必然偏保守或者激进，这个没有绝对。关键业务，我是倾向于偏保守，毕竟是稳定第一，经过验证的东西，我才敢用在业务环境上。不太重要的一些业务，成长的新业务，可以去尝试一些新的技术，适当的做一些激进的尝试。
微博聂永：第一个问题，我认为不要在意是不是架构师，不要为架构而做架构，要
结合实际，用心去思考，在思考的时候思维角度要全面一些，然后全身心就去投入所构建的系统中去，很自然的就能把技术做的很深。第二个问题，关于保守还是激进？其实我可能偏于保守型的，我们在做架构或系统的时候，针对外部依赖就要尽可能少依赖，因为你一旦添加了一项依赖，在后续实践过程中，每一个环节都有可能会出现问题，造成运维层面的难度增加。第三个问题，在做架构的时候，最害怕的问题就是你所引入的每一个所依赖组件，你没有认真的去深度
理解，这样到后面出现问题的时候就很麻烦了。
唯品会张广平：我针对第二个问题。到底是偏保守还是激进，要看一些具体的场景。如果架构师参与到时间比较紧的项目，或者是关键的项目，这些项目做改动对生产环境影响比较大，这时候衡量方案一定要
谨慎。到底应不应该去做一些改动，而且这些改动给我们带来的回报是什么。那么对于新的项目，类似于重构。如果只是在原地踏步，有可能得不到一些回报。所以我们需要去发挥主观能动性，比如说发挥一些抽象思维，对现有的系统做一些充分的调研，大胆提出一些自己的方案。当然这个方案需要跟各个团队去做一些互动，然后去验证。
大众点评陈一方：我其实是偏实用的，也不叫保守，也不叫激进。就像产品的理念一样，少就是美。现在一个系统都很复杂，如果每个人都采取不一样的策略，或者不一样的技术战，其实很难管理，这里是要求简单，大家尽量是统一的。然后这个模块和这个技术的引进来以后，是可维护的。还要对这个系统负责，谁引进来的，谁就要驾驭这个技术战。这个策略总体称为是偏实用的。还要做迭代，加工，调整都有可能的，没有一下子就能出一个非常好的系统出来，都是慢慢进入技术战往上加的。技术站的优劣，要根据自己的用户场景，经营的流量规模来选择，因为长期流量规模就决定了你这个系统会有多大的冲击，将来的瓶颈是什么。
七牛云李道兵：关于第一个问题，我觉得首先是提高眼界，其次是刻意练习。提高眼界主要是多看一些书，多参加一些会议，多了解一些新兴的思路，如何把这些思路
融合到你现在的知识体系里边去。刻意练习主要是两块，如何解决问题和如何评估解决方案的优劣，比如看一个演讲，就尝试先只读问题部分，不看解决部分，自己尝试去解决这个问题，再跟演讲者提出的方案对比，评估一下优劣。
相关文章
