架构师

前言 作为一个90后，我可能有比较深的感悟，大学毕业做了自己的本专业的工作，记得刚出来找工作的时候，基本都是有公司要，就去上班 刚从事这份工作的时候，什么都不会，学到的东西在实际工作中用的不多，很多东西都是靠百度，这样的日子过了一年半，那会感觉目前的薪资已经满足不了我的现状。 后来在自己的努力学习提升下，面试了几家公司，拿到了很多offer，薪资也翻倍了。 对于架构师，是我现在追求的目标，我也有我对架构师的见解，不知道跟大家是否一样。 架构师是一个团队的灵魂，也是团队的核心人物。 首先，必须具有丰富的软件设计与开发经验 。这有助于理解并解释所进行的设计是如何映射到实现中去。 其次，要具有领导能力与团队协作技能 。有着高超的技术，能在关键的时候做出有效的决定。 第三，是具有很强的沟通能力 。架构师需要与各路人马经常打交道，客户、市场人员、开发人员、测试人员、项目经理、网络管理员、数据库工程师等等，而且在很多角色之间还要起沟通者的作用。 架构师一般都是工作8年左右的老司机， 大致的历程是这样的：程序员→高级程序员→架构师 ，每一个成长的过程都需要自己多学习、摸索。 技术更新很快，自己也要不断的充电 ，一个人的资源有限，并且又是刚入行不久，所以就要有有效的资源跟途径去学习，这样才能缩短成为架构师所需要的时间。 虽然现在“996”俨然成为互联网行业的常态，也不符合劳动法的规定

什么是系统架构师？ 系统架构师是一个既需要掌控整体，又需要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师需要有足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。 架构师一直是程序员「羡慕且追求」的高度，今天来说说我眼里优秀的架构师该如何定义。毕竟我也曾经是一名架构师：） 在开始今天的话题之前我说一个和我前公司P9现在已经是P10的对话。 问题是这样的他说公司中间件架构师不熟悉公司业务，很多事落地不了，非常的疑惑。他最近主要任务就是和这些架构师聊天解惑：） 接着他说了一个类比的故事大概是这样的， 我们（架构师）要建设一条高速公路，来分别看看公路建造者（架构师）和司机（业务研发）的视角。 1，建造者 他们选用最好的沙子 水泥 更好的设计图纸和操作流程保证质量和处理异常情况（比如出入口提示，超车，紧急停车带） 2，司机同志 他们关心什么？ 司机关心路宽么，有堵车可以提前告知么。 司机关心路平整么？当然关心，关心。 引出一个的问题：司机（业务研发）关心用最好的水泥么 ？ 想象你是司机（业务研发）你你关心吗？ A，关心 B，不关心 欢迎留言留下你的思考。 系统架构师应具备哪些能力？ 我觉得一名优秀的架构师，在设计系统时需要有以下这四项关键能力：「平衡取舍、预判未来、抽象思维、容错机制」。 1.平衡取舍 一个架构本质上总会有优有劣

今天给大家带来一篇自己翻译的干货《软件架构师之路》。本周Github上升很快的项目。其内容对致力于成为软件架构师（不论前后端）的同学应该都会有极大的帮助。 项目地址: 中文地址 https://github.com/gamedilong/SoftwareArchitect-CN 原文地址 https://github.com/justinamiller/SoftwareArchitect 如果有看完英文原文，发现本文翻译内容中存在问题或者错误的欢迎到中文Git地址PR，如能够对大家起到一定的帮助也欢迎star 内容 什么是软件架构 软件架构的层次 软件架构师的典型工作内容 软件架构师的重要技能 架构师的技术路线图 相关书籍 什么是软件架构? 软件架构师是一名软件开发专家，他可以进行高层设计选择并决定技术标准，包括软件编码标准，工具和平台。 (出处: 维基百科:软件架构师) 软件架构（architecture）是一个系统的基本组织，由其组件、它们之间的相互关系和环境以及决定系统设计和演化的原则来表示。 (出处: 软件架构手册) 软件架构的层次 软件架构可以被抽象的分为几个层次，不同的层次对技能的要求不同。对层次有很多不同的划分，我最喜欢如下这三种划分: 应用级 : 最低层次的架构。聚焦单个具体的应用。 非常注重细节, 底层设计。 沟通仅限入单个开发团队。 解决方案级 : 中级别的架构

来源:http://www.cnblogs.com/Ray-liang/p/3815657.html 国内我们对架构师，项目经理，开发经理或者是技术总监这类职业定位普遍不都不清晰，很多的情况是“能者多劳”，一人身兼数职。达尔文的理论在我们的行业是绝对适用的，我从进入这个行业开始我就不甘于成为淘汰者，而我也由心地热爱着这个行业很年前我就立志要成为架构师（当年流行叫：系统分析员 ）这目标进发。回首这10几年的磨练，我总结了一下一名合格的架构师应该具备哪一些方面的能力以及怎么才能得到这些能力 编码能力 架构师是一个职业，是一种经历了各种磨练与长年开发经验积累出来的。另外我一直认为：不会编码的架构师不是一个好的架构师。我见过很多所谓的架构师完全不懂编码，但总喜欢拿着架构说事。但从严格来说他们并不属于“软件架构师”的范畴，充其量只能算是个“系统架构设计师”，遇到这样的”架构师“我总喜欢说一句话：”Don’t tell me the concepts show me the code!“。 不参与编码并不代表不会编码，如果没有过硬的开发基础，巨量的编码时间积累为基础，在设计软件时一定会忽略非常多的细节，而这将会直接影响到整个项目的成败，试想想当项目经理按照架构师设计的软件蓝图订制开发计划与安排项目资源时由于“蓝图”内存有大量未确定的风险因素，以及由风险触发后所带来的不可预知的结果

架构师 倾向于 通信 、 通信框架 、队列和 分布式框架运用以及阿里云和微软现有分布式组件的运用。 高级软件工程师 倾向于 C#基础、 多线程、锁和数据库索引 （队列和通信也会问只是会问的浅一些） 研发经理 包含高级软件工程师问的这些外，还会问管理方面的知识 我面试的三家公司分别面试了三个职位，将知识点进行了一个表格整理，分值越高就意味着问的越深，不能百度之百准确，只当参考。 职位 C#基础 通信 缓存和队列 数据库索引 数据库锁事务 前端 多线程 数据结构 管理 自我介绍 大数据方案 常用框架 项目介绍 逻辑题 架构师 10 100 100 100 80 0 100 100 30 100 100 50 100 100 研发经理 100 50 70 70 50 0 100 80 100 100 60 0 100 50 高级软件工程师 100 50 70 100 100 50 100 50 0 100 70 100 100 60 知识点细讲 C#基础 主要面些 接口、装箱拆箱、值类型引用类型和线程 可以参考面试基础： http://www.codeisbug.com/Doc/4/63 例如：什么是装箱和拆箱，装箱和拆箱为什么会影响性能。这些属于深问细节，所以要做好防问准备。 通信 主要分为Http协议 TCP协基础知知识，通信框架例如开源的Supersocket RestSharp

经过这段时间的反思和整理，终于对架构有了一个较为明确的理解。架构是产品从无到有以及慢慢壮大过程中所需要的全部技术体系总称，架构过程： 配置、编码、测试、运维、监控分析、安全、运营等一系列技术体系的选型、取舍 技术选型基础上进行规划、设计、实现、迭代、制定相关规范 相关技术及规范运用到产品开发的整个过程中，并在产品迭代过程中对架构进行迭代优化 架构不止包含技术的框架，比如有人用了spring就觉得我已经是架构师了，其实架构并不是这么简单。我们以做一个新浪微博类似产品为例，现实应该是这样的： 产品初期，经典的LAMP快速开发实现第一个版本，功能也无比简单就是加好友，发消息，开发人员也只有一个小的队伍。此时的架构就体现为纯的技术选型及实现，包含了 配置：代码通过git管理，暂时无其他 编码：技术选型为LAMP，基于LAMP的开发框架封装，并在开发团队内制定开发规范 测试：技术人员手工测试 运维：手工发布，主备2台，mysql也做主备 监控：暂不需要 安全：发帖过滤、屏蔽 运营：后台删帖 随着用户的暴增以及功能的增加，产品需要迭代，架构也需要迭代。产品功能增强，性能需要优化，开发人员的增加，此时架构就发生了一个较大的变革： 配置：代码通过git管理，要分为多个模块，不同团队开发不同模块 编码：技术选型增加缓存、消息队列、搜索引擎等，框架封装更加复杂，抽象出基础层和服务层

　　在看了王概凯作者的架构漫谈之后，感触颇多，在这里就软件架构师如何工作进行一些讨论。 　　王概凯作者的网址：https://www.infoq.cn/profile/1279517/publish 　　在生活中经常会谈及或者听说架构师这个职位，那么什么是架构师呢？架构师并不只是做架构工作的那么简单。如果一个人把按时解决别人的问题当成自己的问题的时候，潜意识里会形成一种对时间的恐惧，这种恐惧会使我们想方设法、不择手段的完成工作。在这种情况下是不可能成为架构师的。要成为架构师必须超越这种恐惧，看清楚我们解决的是别人的问题，而不是我们自己完成工作的问题，如果我们把完成别人工作当成自己的最大利益，这个对时间的恐惧自然就会消失，这个时候就自然而然的开窍了，就知道怎么去发现问题了。只有做到这一点，才能在自己所服务的领域建立起自信，成为一个合格的架构师。 　　作为一个架构师，要善于发现问题，主动找上你的问题都不是最根本的问题。要根据别人的利益来发现最根本的问题。“如果问题不解决，究竟谁会有利益的损失？ 如果问题解决了，究竟谁会有收益，谁的收益最大？” 回答了这两个问题就找到了问题的主体。只回答一个是没有用的，因为很多时候这个世界的事情，权责是不对等的。明白了这两个问题，我们只要让事情权责对等起来，让每个人为自己的权利产生的结果负有义务，大部分时候我们自己根本就不需要做什么，问题就都解决了

　　说起软件架构师，我只能说我几乎没有任何了解。听名字可以看出软件架构师是管理软件架构的，但是软件架构又是什么？昨天，软件体系结构这门课开课了，老师提到了软件架构，课后我又看了看架构漫谈的几篇博客（ https://www.infoq.cn/profile/1279517/publish ），可以说是简单的了解了软件架构以及软件架构师的工作。 　　架构的英文是 Architecture，在Wikipedia 上，架构是这样定义的：Architecture (Latin architectura, from the Greek ἀρχιτέκτων arkhitekton"architect", from ἀρχι- "chief" and τέκτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures。这句话的翻译为中文是：架构(拉丁当时从希腊ἀρχιτέκτωνarkhitekton“架构师”,从ἀρχι——“首席”和τέκτων“建设者”)是过程和产品的规划、设计和建造建筑物和其他物理结构。博客里举了早期社会分工合作的例子，人类通过将生存这一目标分解为各个小目标，有人负责种田

如何成为一个架构师？ 　　在大学期间我曾多次听到“架构”这个词，认为这个一个非常高大上，非常高深的词。通过阅读《架构漫谈》，我跟着作者举的一个个例子逐渐理解了什么是架构。首先，架构不是凭空产生的，它产生的原因是： 1，必须由人执行的工作 2，每个人的能力有限 3，每个人的时间有限 4，人对目标系统有更高的要求 5，目标系统的复杂性使得单个人完成这个系统，满足条件 2，3 　　其次，架构是什么，或者说一个架构师需要做什么： 1，根据要解决的问题，对目标系统的边界进行界定。 2，并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。 3，并对这些切分出来的部分，设立沟通机制。 4，根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。 　　举个例子：我认为 好的架构师就像一个导师，带领一队学生向同一个愿景前进； 　　（1）首先分析任务，确定要解决的核心问题是什么，其他的问题是什么，这些问题如果解决，什么人会受益，如果没解决，会影响到什么人； 　　（2）接着导师会根据每个学生的能力合理的切分任务并分配任务，确保每个学生都会去做最擅长的领域的工作； 　　（3）其次导师在学生之间建立一定的工作机制和沟通机制，根据每个学生所负责的工作分配成为一个个大的模块

下面对漫谈架构的每一章进行一个总结 一）第一篇：讲的是到底什么是架构， 在我看来 ： 就是 把一整体划分为不同角色， 各自完成自己的部分 ， 最后有机的融合在一起 。 然后通过一个早期的例子来笼统地概括他的出现。 在最早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，整个人类都是独立的个体，不相往来。为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，可是人每天生活的基本需求没有发生变化，还是衣食住行等生活必须品。但是一旦多人分工配合作为生存的整体，力量就显得强大多了，所以也自然的形成了族群：有些人种田厉害，有些人制作工具厉害，有些地方适合产出粮食，有些地方适合产出棉花等，就自然形成了人的分群，地域的分群。当分工发生后，实际上每个人的生产力都得到了提高，因为做的都是每个人擅长的事情 （二）第二篇：讲的是认识概念。架构实际上解决的是人的问题， 举个例子， 看到一个东西，比方说杯子， “ 杯子 ” 就是一个名字，指代的看到的东西就是相，就是事物的相状。我们一听到 “ 杯子 ” 这个词，脑海里就会浮现出一个杯子的形象。而 “ 杯子 ” 这个词，是用来指代的是这个相状的，叫做名。合起来就叫做 “ 名相 ” 。每个概念 都是因解决问题而产生的 ， 最后 我们把解决问题的解决方案， 命名了一个名字 ，这个名字就是概念。