架构组织形式的讨论，以及架构师之路的建议

架构师小组交流会：每期选一个时下最热门的技术话题进行实践经验分享。
第二期：本篇文章是对于《来自滴滴、微博、魅族、惟品会、点评关于全链路压测等问题实践分享》的续接。
参与嘉宾：滴滴技术负责人彭令鹏、魅族系统架构师何伟、惟品会应用架构负责人张广平、新浪微博技术专家聂永、大众点评交易平台技术负责人陈一方、七牛云首席架构师李道兵。
本文是对这次交流的整理，欢迎探讨。

第二轮：话题交流
主持人：你们以为是须要有统一的技术架构部门，仍是不须要有统一技术架构部门，各个业务部门本身独立往前发展？

惟品会张广平：若是咱们有一个通用的基础架构，这样开发的学习成本比较低，学习一套，而后他能够持续的开发。那若是有多套框架的话，对于开发人员学习成本比较高，另外就是运维的成本。其实任何一个系统，它不是一个独立存在的东西。要上线的话，还须要去作运维。简单举个例子，咱们开发了一套日志监控的框架，叫 Mercury，这个框架看起来技术和现有的一些比较流行的东西差很少。好比说用kafka，之类的等等的一系列做业。若是要运维，须要几百台机器才能这套系统玩得起来。若是咱们各用各的框架，对于公司来讲成本很是高，运维上去之后，每一个框架都要去建一个运维团队去运维。刚开始是有这个问题，开发的东西很难推出去，刚开发了基础组件出一点点问题，而后就被无限地放大，就没人用了。我刚提到那个重构，咱们本身去招聘一个团队，也是由于咱们的CTO支持，给了咱们一个团队，让咱们去把这个重构作起来。当咱们核心的服务一点一点接进去，发现效果很是好，后面接入的团队愈来愈多。咱们确定也不能强行的去压，由于每一个团队他们都有KPI。咱们当时是采起渐进的方式，一个一个模块去接。

 

滴滴彭令鹏：我仍是倾向于业务架构跟着业务技术部一块儿走。由于不管是从百度的经验，仍是在滴滴的感受来说，咱们确定是须要一些最基础的架构，像消息队列、存储、计算这些，这个能够交给基础架构去作。可是作业务架构，我以为仍是要很是贴近业务，我的感受，以前碰到过很多作基础架构的同窗，他们作的架构其实和业务，好比说在延迟，或其余方面的一些需求，其实相差仍是很大的，用起来不那么顺手。

 

魅族何伟：由于基础架构实际上是你们都承认的，业务架构它必定是跟业务组的，由于业务的场景，好比原来技术架构开发MQ的框架，它的框架可能MQ正常，技术架构团队作出来的可能就是，消息的基本特征能发能接，业务要求是消息到达的时序，消息到达有延迟，它有时候就要求延迟，有时候这个消息必须在这个消息前面有持续的。像这种的话，架构团队是不了解的，仍是要从新作。

 

滴滴彭令鹏：我以为从整个团队来说，可能在组建初期，这样作是可行的。但随着业务发展，团队确定会去招一些新人，但新人其实他对业务会愈来愈不了解。而老人可能会逐渐偏向于作顶层设计，具体落地的时候，到最后新同窗会实施的很差，那基本上知足不了业务需求。像百度网页搜索部和其余部门原来都是有本身的基础架构的，在2011年联合成立了一个专门的基础架构部，最开始业务部门和架构部门还愿意合做，但到2013年之后，基本上就不相往来了。

 

惟品会张广平：咱们当时成立了一个架构评审委员会，咱们在推的同时，也经过委员会去作一些强制要求，好比说每一个项目咱们都来作评审，若是你不用一些标准的东西，或者不按照一些比较好的方法去解决，咱们就不让他上线。

 

七牛云七道兵：若是有基础架构，其实最担忧的事情，就是基础架构的东西卖不出去，就是业务部门不买基础架构部门的帐。若是是各自作的话，就比较担忧效率问题。更可能是一些企业前期与后期的策略。

 

大众点评陈一方：技术架构实际上是跟组织架构走的，或者是跟业务架构走的。基础架构其实和组织架构相关的。

 

第三轮：架构师能力提高的建议

主持人：这里有三个问题，你们挑一个来发表本身的观点。

一、不少架构师都是从程序员转过来的，那么对于一个想成为架构师的程序员，你有什么好的建议?

二、不一样架构师的在选型上会有不一样的作法，有的偏保守，有的偏激进，你的观点是什么？为啥你会作这样的选择？

三、在作架构设计时，你最惧怕什么状况？为何？

 

滴滴彭令鹏：我选程序员转型。由于我作一线的工做挺多的。很重要的一点是，咱们不能纯写代码，还要留充足地时间去思考和抽象。由于我发现不少一线工程师他干了五六年，换了一家公司，或在一家公司呆了好久老是在写相似的业务代码。若是没有思考，我以为他的能力仍是上不去。第二是咱们作一些事情要打破边界，不少程序员会以为，这东西不属于个人，我不去接触，或者说这个东西c++的，我不熟，我也无论等等，这样知识面较窄。第三作了架构师之后，仍是要贴近业务。并且对于一个程序员转过来的架构师，须要注意的是不要纯看技术，更重要的是贴近业务去落地。第四咱们作一个东西，好比作服务治理，你战略上能够很大，有一个理想目标在那里，可是具体落地的时候，你每一项战术要作的很是细，才有可能作成。整个是一个螺旋迭代的过程。

 

魅族何伟：我刚才仍是第二个问题，其实前面都很认同，一个是基础打好，而后就是学习一些业界架构方面的经验。我补充一点，作程序员，你要找机会来锻炼本身，而不是给你安排什么，你就去作什么，而是要多思考，勇于跟别人PK。第二个问题架构选型，我以为没有必然偏保守或者激进，这个没有绝对。关键业务，我是倾向于偏保守，毕竟是稳定第一，通过验证的东西，我才敢用在业务环境上。不过重要的一些业务，成长的新业务，能够去尝试一些新的技术，适当的作一些激进的尝试。

 

微博聂永：第一个问题，我认为不要在乎是否是架构师，不要为架构而作架构，要结合实际，用心去思考，在思考的时候思惟角度要全面一些，而后全身心就去投入所构建的系统中去，很天然的就能把技术作的很深。第二个问题，关于保守仍是激进？其实我可能偏于保守型的，咱们在作架构或系统的时候，针对外部依赖就要尽量少依赖，由于你一旦添加了一项依赖，在后续实践过程当中，每个环节都有可能会出现问题，形成运维层面的难度增长。第三个问题，在作架构的时候，最惧怕的问题就是你所引入的每个所依赖组件，你没有认真的去深度理解，这样到后面出现问题的时候就很麻烦了。

 

惟品会张广平：我针对第二个问题。究竟是偏保守仍是激进，要看一些具体的场景。若是架构师参与到时间比较紧的项目，或者是关键的项目，这些项目作改动对生产环境影响比较大，这时候衡量方案必定要谨慎。到底应不该该去作一些改动，并且这些改动给咱们带来的回报是什么。那么对于新的项目，相似于重构。若是只是在原地踏步，有可能得不到一些回报。因此咱们须要去发挥主观能动性，好比说发挥一些抽象思惟，对现有的系统作一些充分的调研，大胆提出一些本身的方案。固然这个方案须要跟各个团队去作一些互动，而后去验证。

 

大众点评陈一方：我实际上是偏实用的，也不叫保守，也不叫激进。就像产品的理念同样，少就是美。如今一个系统都很复杂，若是每一个人都采起不同的策略，或者不同的技术战，其实很难管理，这里是要求简单，你们尽可能是统一的。而后这个模块和这个技术的引进来之后，是可维护的。还要对这个系统负责，谁引进来的，谁就要驾驭这个技术战。这个策略整体称为是偏实用的。还要作迭代，加工，调整都有可能的，没有一会儿就能出一个很是好的系统出来，都是慢慢进入技术战往上加的。技术站的优劣，要根据本身的用户场景，经营的流量规模来选择，由于长期流量规模就决定了你这个系统会有多大的冲击，未来的瓶颈是什么。

 

七牛云李道兵：关于第一个问题，我以为首先是提升眼界，其次是刻意练习。提升眼界主要是多看一些书，多参加一些会议，多了解一些新兴的思路，如何把这些思路融合到你如今的知识体系里边去。刻意练习主要是两块，如何解决问题和如何评估解决方案的优劣，好比看一个演讲，就尝试先只读问题部分，不看解决部分，本身尝试去解决这个问题，再跟演讲者提出的方案对比，评估一下优劣。