老方的生活日记
第一，对市面熟悉的来源架构熟练，并清楚内部原理，同时在真实项目中熟练使用过！第二，有企业级体统架构搭建经验！满足这两点基本可以算是一个系统架构师！
深圳程序员大河
如刚才那位大侠写的那样，不要太在乎称谓，随着年龄的增长，写的代码的增多，开发的软件的数量越来越多，你会觉得那个称谓真的不重要。我业余编程快二十年了，其中VB坚持了15年，其他的如VC,ASP零打碎敲的都用过，这编程其中的乐趣不是别人叫你一声高手或什么师能换来的。纯粹是爱好，我的专业不是这个。
debugtheworld
什么是架构师，架构师要做什么事情，为什么Java的领域里，会更注重架构师？
很早很早之前，我对于架构的概念一点都不理解，依稀记得，架构（ architecture）这个词，来自于建筑领域。
这对于我这个没写过几行代码的人来说，瞬间就有了一种“不明觉厉”的崇拜感。
架构，感觉好厉害的样子，从名称上来说，好像是设计根骨，设计底层，设计最核心的东西的人。
架构师，一定很NB，我什么时候能成为架构师呢？
后来懂了一点点代码，去写增删改查，更是体会不出来架构的概念，不就是Sql语句吗？明明DBA更厉害啊，做各种的慢Sql优化，所有的Sql都要让DBA审核，DBA对于Mysql，或者是Oracle的各种性能调忧很厉害，而熟悉业务的开发人员又常常能写出几万行的SQL语句。
我看到这些头都要炸了好么？
所以，倒底什么是架构？整个系统只有一个WEB，Spring MVC+Spring+Hibernate搞定一切，开始做需求分析，实际上就是设计表结构而已，剩下的就是查查查，改改改，删删删。
直到某天，我知道一个词，缓存。
缓存这玩意儿，在很早之前学习各种基础课程的时候，了解过一些，一级缓存，二级缓存什么的，LRU我好像也懂一点点，但是，在系统里，缓存算是什么？
在公司里，那个架构师，画了一张图，告诉我们，这台机器上，放了一个Memcache，然而我们都不懂，他只解释了一句，这个Memcache是缓存。
我的第一个困惑就是，所有的请求都要再次转发到另一台机器上，把数据取出来，单个请求可能不算什么，每天有几十万次请求，这中间的损耗不大么，为什么不把Memcache放到本地机器上呢？
他没解释，只告诉我说，不大，Memcache就是要放在另一台机器。
在当时，我不清楚内网和外网的差别，也不清楚访问Memcache的请求倒底是需要多少MS，更不理解，把Memcache放在和业务层一台机器，或者是分开放的差别倒底是什么。
但这个问题一直困惑着我，简单来说，这其实算是一点点架构师要做的事情的萌芽，一个系统中，如果拆解出来了很多模块，倒底应该部署在哪些机器上？架构师会解决这些问题。
后来，到了搜狐之后，我突然间发现了我之前学到的东西，在搜狐的技术大神面前，直接被轰成渣。
负载均衡是什么？热备又是什么？
穿透DB是什么意思？怎么我取数据库里取一个值，数据库里没有，这种空数据的请求会把DB打跨？我还要把这些为Null的请求单独缓存起来？
本地缓存做为一级缓存，Memcache做二级缓存？
“对缓存来说，最关键的设计就在于失效策略是什么。”大神镇定的看着我。
我很惶恐，感觉能把失效策略设计出来，很不容易。
不同的应用场景，对于缓存的要求不一样，对实时性的要求也不一样。榜单这种一天更新一次的，每天晚上定时生成一次就好了。后台更新，但是要注意，一定要直接生成，直接切换，不能让前端用户访问的时候，再去生成。
对于名字这种东西，用户改完之后，必须立刻更新缓存，包括本地缓存和远程缓存。
这算不算架构中的一部分，根据不同的应用需要，去设计不同的策略，同时把这些场景规范化，成为一整个团队都要去遵循的标准？
我不知道，我只知道，能Hold住团队里所有人的那个人，技术一定非常NB，团队里的每一个人，都会质疑，如果你Hold不住全场，怎么能推行下去？
当时近30的技术团队里，每一个都是神一样的存在啊，谁能Hold住30多个神。
而且，原来不应该把所有的代码放到一个WEB里，原来分布式是这么回事儿，原来一个系统，是由多个子系统构成的，原来还要分层，原来封装和抽象是这么个意思。
WEB层是一层，通常可以通过LVS部署两台到三台，或者是更多的，Service一层用来处理业务逻辑，缓存层用来扛并发，一定要藏在Service里面，Controller调用Service的时候，并不需要知道，数据倒底从哪来的，每一个Service使用什么样的缓存策略，完全不需要Controller层知道，持久化，对，对于大型应用来讲，Mysql只能用做是持久化，Mysql的单条访问速度并不查，只是在并发能力太差，扛不住。但是，有可能数据量过亿啊？
过亿怎么办？是用分库，还是分表？读写分离要不要做？一台服务挂一台数据库，哪些数据库应该放在一个实例里，哪些应该单独拆出去？每台服务器的配置是什么？
我大概知道一点点，架构师要做哪些事情，他就是要把这些大的骨架定好，然后我们去填充里面的内容。如果骨架定歪了，其余团队必然跟着歪。
这时候有了一系列的问题，第一个，Controller和Service之间，Service和Service之间，应该通过什么调用？
RMI，这是惟一的选择。用thrift，或者是ProtocolBuffer，或者是Rest实现的RPC？
这是架构师要考虑的事情，如果是用RMI，我们是要自己实现，还是要找找是否有好用的开源的框架，在其他的系统里被证明了是有用的？
大神们花了两周的时间，对当时流行的开源框架过了一遍，最终选定了Tuscany，到现在我都觉得设计精美，完暴Dubbo的东西，真的是一点都不想切到Dubbo上去，毕竟“曾经沧海难为水，除却巫山不是云”。
直到最近几年微服务兴起的时候，我还是同样的目瞪口呆，这跟2009年搜狐当时做白社会的架构比起来，优势倒底在哪里？差别好像没有那么大啊，而且Tuscany实现的更完美，只是使用的时候要有更强的约束，因为Tuscany太强大了~强大到有一点点重，必须要做简化，而且，Tuscany的开发团队不怎么维护了，白社会当时做的东西，还是大神花了两周的业余时间写了一个Scallop，增加了Tuscany的负载均衡的功能。
但是，倒底用什么，不用什么呢？除了Tuscany，还讨论过要不要用Hadoop，要不要用ActiveMQ，要不要用Erlang。
每一个技术框架的选择，都经过讨论，验证，测试，最终在全团队里推行。
这是否也是架构师的职责？这个架构师太厉害了，他需要从前到后都要懂，他需要制定关键的技术细节，他需要给出最佳实践，他需要了解业界所有流行的解决方案，他需要去猜测Facebook怎么解决问题的，Twitter怎么解决问题的，Google怎么解决问题的，这些解决方案可不可以拿过来，也同样适用于我们自己的场景。
他需要精通分布式，Nginx或者是F5，微服务，缓存，持久化，消息队列，他需要熟悉所有这些技术细节里的最常用的解决方案，不能有遗漏，也不可以过度设计，他决定的不是他一个人喜欢的风格，他决定的就是整个团队，在项目死亡之前都必须遵循的规范，现在的团队成员，和未来的团队成员，都必须遵循的体系，而且，如果在未来，这些架构体系有不合理的地方，那就麻烦大了。
这样的架构师，还要肩负着一个重大的使命，修复开源软件的Bug。
在很早之前，我一直误以为开源软件是很厉害的很NB的东西，我一直以为这是完美的，很久很久之后，才明白，所谓的完美，都是用血和泪塑造而来的。
不经过各种各样的验证，环境，使用的测试，很难达到一个上线标准的稳定，即便是上线了，也有可能会出现之前完全预料不到的问题。
可是，如果你选择了这个框架，出了问题，谁去解决？
架构师，他要开源码，理解这些开源框架的思路，然后去找有可能产生问题的地方，再去修复他。
我一直都觉得，能看懂别人写的代码的人，都是神。
某段时间我去看一个heritrix,看的我神清气爽，各种层出不穷的继承，各种抽象类，连着三天我欲仙欲死，更加坚定了我死也不要，也不允许其他人在项目里使用继承的决心。
但是Heritrix从外表看起来特别牛，他的抓取策略也很NB，用的分布式抓取的解决方案非常轻巧。可是我我实在是不想再去读一次了，在当时不读不行，资料太少。
那么，一个架构师，要对这些源码都了解么？又或者是，他必须具备，需要他去读源码，他就必须读源码，而且去优化的能力？这大概比提前懂源码，更神奇。
因为是有时间要求的啊，简单来讲，他需要在一个有效的时间内，去弄懂所有的底层的东西，说句实在话，当有同事嘲笑我都没有完整的看过TCP/IP协议详解的时候，我真的是无话可说的。
对于特别底层的东西，我确实了解的不够多，可是架构师们不一样。
有了这些，就可以称之为架构师了么？
架构师需要懂业务么？是不是就可以每天看技术，写底层框架（比如我们原来在搜狐用到的DAL，数据访问层，用起来简直是神器的东西）。
没有不懂业务的架构师，所有的架构，都依赖于业务。所有的架构师，也必须要去写业务代码，不把自己设计的东西，用在真正的项目里，恐怕他们自己都不会知道，这种架构设计的合理性在哪里。
在某团购公司上市之前，他们的CTO拿出来了他们的架构图给我看，在给我看之前，所有的技术术语都一样，但是当我认真看了架构图之后，我的困惑。。。。
为什么Memcache要放在Controller层被调用？ 不应该是放到Service层吗？
怎么会出现你说的，一个Serivce负责维护的数据，也有可能被另外的Service去更改的情况？每一个Service对数据的操作，必须是独立的啊，除了这个Service，其他的任何服务都决不允许直接更改DB啊。
而且，怎么Service拆分了，DB不拆分呢？这样的话，压力大的DB会把全站拖跨的啊。
那张架构图我看到之后，感觉自己的认知被突破了，原来可以这么做，原来同样的，类似的技术选型，可以做出来如此艰难的东西？
就在我以为这其实就差不多是架构师的全部的时候。
在最近一段时间，我突然间发现了一个问题。
为什么有的人代码写的这么烂，很多写死的代码，一点儿灵活性都没有，更没有规范，完全就是堆压。
为什么有的人根本不知道怎么去抽象，并不清楚怎么样积累成公共组件，为什么他们改一个问题，通常会引出更多的问题？
为什么他们的代码里的实现方案，让人看完之后恨的牙痒痒，想改又完全不能改，毕竟，正常工作的代码才是好代码？
很大程度上是因为，很多程序员，不懂的代码的扩展性，不会面向未来编程。
怎么叫做面向未来编程？
一个好的工程师，在听到需求的时候，可以根据自己的业务能力，判断出来这些需求中，哪些是有可能变化的，哪些是不太可能变化的。
针对这些变化的内容，在编写的过程中，不会写死，而反复确认不可能会变化的需求，会写的简单一些，防止过度设计引起的复杂度。
简单说，当他拿到需求时，并不单纯是考虑这个需求怎么实现，还会考虑，自己设计的架构体系，扩展性在哪里，在他的眼里，看到的需求会被分解，折分，然后自己的技术方案，会挨个分解，分配。
在完成设计之后，他会很清楚的知道 ，自己设计的系统里，哪些变化是支持的，随便你改，我只需要改动一个很简单的内容，哪些是你绝对不能改的，你要改，我就必须花很大的代价，特别是在已经有线上数据的时候。
而且会拿着自己的架构体系跟PM沟通，讲清楚。
什么样的变化是支持的？短信通道是有可能变化的，而调用短信通道的地方可能会有点多，所以我必须把短信通道抽象，并封装在一个公共接口，如果需要更换短信通道，我可能只需要更改一个配置文件就好了。
那么什么样的变化是不支持的？我不需要不停机就更换短信通道的功能，除非你在后台系统中提前配置好，或者是有明确的需要，我做出这么一个东西出来。往往在前期，不会用到。
为什么？
在创业初期，短信通道往往用于用户注册，一旦出问题，就是生死问题，必须要有一个备份，运营商一怒封掉你的通道，很常见。
而重启一次服务，在创业前期，往往没有那么严重。
所以，这些技能，是不是也应该归纳到架构师的职责里去？
架构师从开始就要考虑选型，从语言开始，从业务开始，要对这个领域里的开源框架熟悉，了解，要能解决疑难问题，要懂安全，要会备份，要学会面向未来编程，还需要什么？
还需要DevOPS.
在持续集成的年代，在服务器规模越来越大，在云服务器的年代，在异地存储，冗灾，在全球化越来越快的年代。
运维的重要性已经到了一个很核心的程度了。弹性伸缩，自动扩容，灰度发布等等等概念，要求，都在冲击着架构师这个概念的定义。
如果说之前的架构师，更多的是在系统开发前，现在越来越偏于系统上线后。
还包括数据分析，日志分析，等等等等，对了，还没有提到Nosql DB，实时搜索，知识库，算法这一系列的东西。
每一个领域都在细分，每一个概念都在深化。
简单说，架构师确实和语言无关，但是又绝对和语言有关系。
你可以说，架构师就是在做选型，但是只会做选型，肯定做不出架构师。
Java更需要架构师，因为他本身就是各种开源框架，不对这些框架了解的清清楚楚，你很难做出一个好的选择，而一旦架构被固定，实际业务人员的开发，又会变的简单很多。
说到了现在，我有没有讲清楚架构师是什么？
而你，还想要做架构师吗。
反正，我说自己是架构师的时候，我的内心是羞耻的，我知道 ，我远远没达到架构师的能力。
康康看世界
你这个标题有点乱，我来笼统的回答一下架构师需要哪些能力吧希望对你有所帮助
想要做架构，空有一身技术是远远不够的，知识的深度和广度，往往会决定一个架构师的架构能力。而这些知识，从你踏入 IT 行业那一刻起，甚至更早就应该开始储备了。
那么到底什么是架构师？如果有一天把你丢到架构师的位置上你会怎么做？ 做什么呢？以下来具体阐述下一些看法和建议！
一、两种架构师工作五年以上的童鞋，或多或少都会有这样的经历：
在小团队或者项目中承担非明确的架构师职责，我们做
- 项目或者产品的关键设计和实施；
- 负责产品基础设施；
- 引入新的理念，框架；
- 解决团队中的复杂问题；
- 在团队成员中享有较高的声誉；
- 被老板认为是团队的关键人物。
如果有一天我们决定（或者其他原因）去做一个专职架构师，那么这两者会有什么区别呢？是否只是之前的方式的延续就足够？
我把第一种状态称之为“兼职架构师”，因为处于这种状态下的同学大部分的时候担当开发人员、PM的角色，只有在小部分时间承担了架构师的部分角色。做的绝大部分事情是自己可控的，自己做架构自己做实施或者在小团队中推行。
而后一种“专职架构师”则面临的是：他们不负责具体的业务系统，而又对所有的系统负责，他们也很少直接负责项目，但是职责却要求他们必须对项目要有提前把控，他们面对的是更大的团队，更大的问题域。
当然每一个人对是否应该存在“专职架构师或团队”都有自己的想法，从阿里的历史来看单独的架构团队也是分分合合。在这里不去探讨，我们关心的是如果有，可以怎么做。
二、专职架构师的职责首先要弄清楚的是专职架构师的职责到底是什么？
微软对架构师有一个分类：企业架构师EA(Enterprise Architect)、基础结构架构师IA(Infrastructure Architect)、特定技术架构TSA(Technology-Specific Architect)和解决方案架构师SA (Solution Architect)。这个分类是按照架构师专注的领域不同而划分。在阿里除了EA之外的领域大家可能会同时涉及到，只是不同的时期偏重点不一样。比如前面说的“兼职架构师”可能偏重SA？专职架构师偏向IA+TSA。另外一个角度专职架构师更多考虑问题域和相应的系统架构，而“兼职架构师”更多的是产品的系统架构，具体来说我认为专职架构师重要的职责如下：
职责一：全局的技术规划
架构师第一个最重要的职责是技术规划，架构师最重要的产出是架构，架构就是蓝图，就是阿里常说的一张图。画蓝图就是做“全局的技术规划”，这张图上有什么？ 没有什么？什么时候有？什么时候没有？当你尝试去画图的时候一连串的问题拷打着你。对于一个架构师的心力和体力都是很大的考验。只有这张图非常清晰明确才能指引整个团队在同一个时间向同一个方向前进。
为了这张图你必须和业务紧密沟通，你必须有对应的技术深度和广度，在选型上有自己的方法论，敢于做出判断和决策。
另外一个重点是全局。全局我的理解是全面+格局，全面就是你的技术规划包含各个方面的，在所有的领域都有明确的指引，所以这张图本质是一系列的图的集合；格局上不要只关注短期利益，更多关注长期利益。不止关注团队利益，更多从公司角度出发，只有这样长期才能为团队带来更多的成长。
职责二：统一的方法&规范&机制
架构师第二个重要的职责，我们不仅仅要提供蓝图，还要提供配套的方法论&规范&机制来保障有序进行。蓝图确保整个团队在同一个时间向同一个方向前进。规范确保前进是有序的。为了有序，你必须拆解你的图，纵向、横向、功能内聚等等纬度拆解到权责清晰对等。这是一项相对复杂且繁琐的过程。
职责三：完备的基础构建
除了蓝图确保整个团队在同一个时间向同一个方向前进、规范确保前进的有序的、我们还需要提供强大的武器库，基础构建的完备程度决定你的团队装备是小米+步枪，还是飞机+大炮。完备的基础构建是否全部作为实际架构的职责，可以因情况而定，比如是否有实体的架构组。但是架构对此应当负责。
职责四：落地的规划才是架构
如果规划不能落地就是传说中的PPT架构师，我甚至觉得这是对专职架构师最大的挑战，前面的几个职责更加偏向硬实力，而这一个更多的是软实力的体现。专职的架构师如果不去关注落地的话慢慢就会架空，变成PPT架构师，那差不多就game over了。
三、专职架构师的权利正如前面说到对架构师最大的挑战是落地层面，实际上“完备的基础构建”已经涉及到落地层面的事情，但是和完备的基础构建不同的是整体架构的落地涉及到方方面面，面临是更多影响因素：和业务的关系、组织结构、权责定义等等。
所以有人从“架构师的权利和职责”的角度出发推论谁合适做架构师。得出的结论是一个组织的领导者。因为只有他才能调动、协调组织。也有人认为架构师既不能完全负责技术团队，也不能完全游离在技术团队之外。因为负责容易屁股决定脑袋，游离就只能靠个人声望值吃饭了。
如正架构分类中EA的存在，很多领导者也确实身体力行的践行架构师的职责，然而精力终有限。实际上更多是平衡的过程。当然最高境界是影响力。
四、专职架构师的考核针对前面的职责怎么考核？或者怎么设定自己目标？虽然说在不同的团队阶段，不同外在环境，不同的权责情况下不一样，但是在结果导向的背景下落地肯定是架构师重要的考核指标之一。
考核一：全局的技术规划
相比其他几项这一项是最重要又最难评价的，技术规划的好坏、全面性、前瞻性都是定性的描述，如何指引我们做出一个理性的评价呢？回归到本质上“技术规划”只是一个指路灯，团队中每一个人能不能看到“指路灯”就到达目的地是指路灯价值的体现。所以无论是唯价值论还是唯口碑论衡量的其实是同一个东西。
考核二：统一的方法&规范&机制
这一项的考核就相对容易多了，无论是业界还是每一个架构师本身都有自己的一套方法，所以只需关注这些东西对应的产出。
考核三：完备的基础构建
我认为在大公司，大部分重量级的基础构建已经是非常完备，对于架构师来说更难的不是从0到1，而是克制、边界和从1到2的过程。对于架构师也好、技术团队也好“从0到1”总是充满了吸引力，加上技术人的特征，大公司技术史上永远不缺少重复的轮子，创建这些轮子成就了一代一代的同学，拆除这些轮子再成就了一代的同学，所以克制尤为重要；有了克制跨团队的合作就尤为重要，对应的有两个点一是清晰边界，二是共建。
考核四：落地的规划才是架构
虽然说落地是非常不控的事情，但是考核却很容易的：做到就是做到、没有就是没有、质量好就是质量好，标准非常清晰。过程中只需要紧跟拆解的事情结合实际的组织和业务情况做出决策。
五、实施的一些想法对现阶段团队的情况来说，我认为第一是建立“架构语言”，有了语言才有沟通协作的基础，所谓的“架构语言”并不是什么新的东西，而是产品的业务架构，用例和领域模型；研发的应用架构，组件和时序图； 运维的部署架构等等。
第二是建立“认同体”，无论是通过技术能力、知识传递、领域组织等各种方式逐渐形成“认同体”，且在其中形成架构体系对应的人员体系。
第三永远做服务者，架构师对应的客户是团队的每一个成员，必须始终保持客户第一的心态。架构师存在的目的是成就研发团队每一个同学，我们提供必要的平台、服务和空间，然后彼此成就。
sun4584
你好，很高兴回答您的问题：
\n
{!-- PGC_VIDEO:{"thumb_height": 1080, "vposter": "http://p0.pstatp.com/origin/tos-cn-p-0000/6138ed61ddee4e77ac85658bfbd7f29b\
一个IT男的生活号
这个要看是什么系统的架构。我做游戏开发。在我工作得第7年做了一套自己的游戏框架。这是在工作的时候发现没有一套自己的框架一旦公司有变动就容易被裁。于是就开始写自己的服务器框架。对于游戏服务器框架我认为有两层含义。一个是整套系统的框架。就是不同类型的服务器协调工作。另一个是单个服务器高效稳定的运行。第一点需要工作经验。理解不同的服务器框架。第二个需要的是知识面。需要解决实际问题。其实一直写下来也是在不断的调整。不同的游戏类型基础框架是不一样的。对于游戏的功能则要简单很多。基本就是逻辑功能。有时候认为写框架很难。其实只要有钱有时间问题都能解决。到现在中国做游戏的换皮的多。一般的小公司不愿意做。大公司有稳定的框架。所以机会很少。就说你能写游戏不上线也没有多大用处。其他行业不了解。
罄竹10
无他，惟手熟尔。只是别人嘴里的一个称呼。就算自己在公司是所谓架构师，自己别太当回事，不然容易被人喷。保持谦虚，多学习。天外有天，人上有人。
猿猿老罗
最重要的一点谦虚 谨慎 忌自大浮躁 。
保持对技术的敬畏 ，cs理论扎实保持学习
再者对业务的熟悉，只有适合业务的架构才是合理的。
将计就计00
感觉自己可以独立完成一个中等规模的程序设计就可以了，设计里面要包含设计模式，算法优化，分布式等支持框架，开发周期设计等内容就差不多了
Oo香猪仔oO
看个人成长喽！有些人运气好，工作顺风顺水，技术栈在工作中就获得了，有些人很背，只能靠自己自学来积累技术栈，运气背又不自学的就是混吃等死型呗！
