系统原理分析架构-开篇 （对于架构师与开发语言及被青春饭的一些想法）

感谢朋友支持本博客，欢迎共同探讨交流，由于能力和时间有限，错误之处在所难免，欢迎指正！

如有转载，请保留源作者博客信息。

tantexian的博客：my.oschina.net/tantexian

如需交流，欢迎大家博客留言。

首先附上，高并发高性能架构图：



ppt链接：https://my.oschina.net/tantexian/blog/791694





一、序：

怀着求知、进取的心开启本文,望与大家共进步。

细想一下，自己用过的语言应该也不算少。简述之、从最底层开始，画过电路板（GPS导航）。用过VHDL硬件编程语言写译码器。用汇编语言写过驱动、微操作系统中断向量表等。 弄过keil c嵌入式开发。工作用c语言更多的是写些驱动、串口，I2C、算法之类。c++嘛，写过一个简单项目，没深究。弄linux的话，少不了要写shell脚本的，所以shell语言当仁不让要加入到开发的语言队列中。接下来，就开始了神奇的上层语言开发之旅。java，本人最喜欢的开发语言。也算是自行花时间研究比较深入的一门语言了。Next,弄过一段时间php，虽然曾经LAMP（ Linux+Apache+Mysql/MariaDB+Perl/PHP/Python ）架构风靡整个互联网（中国公司使用php作为上层语言居多），开发效率极高。用php写过一个公司内部工单系统、但是我对php确实不怎么感冒，可能对java更过偏爱的缘故吧，情有独钟。当前随着阿里系，京东派把网站整个转为java架构体系，java在国内也是空前火热。谈谈神奇语言--python，断断续续用了三四年，整体说来也算是自己比较喜欢的一种语言。python在国外当然是一片火热，不过在中国不温不火。猜测原因：中国懂python的太少，精通的更少。再说国内用python的公司也少，有名点的也就豆瓣大规模用python 。结论：java一抓一大把，python一人难求。不过在google等大牌的大力推崇下python发展势头还是很迅猛。（PS: 最近由于人工智能的强势兴起，再则TensorFlow的开源将python也带入了空前的火热）不过python效率比java要低些，而且是小众语言，后续发展有待验证（目前似乎google也开始用golang在捣鼓人工智能）。最后顺带列出捣鼓过的前端语言：html、css、javascript、jquery(DIY 过 js分页插件)。前端语言似乎没太要说的必要，大部分公司用的都差不多。

说了这么多总结一下：

使用时间排序：c > python > java>golang > 其他

喜欢程序排序：java > golang>python > c > 其他

二、架构师杂谈：

首先 参考一下微软架构师分类： 企业架构师EA (Enterprise Architect)、 基础结构架构师IA (Infrastructure Architect)、 特定技术架构TSA (Technology-Specific Architect)和 解决方案架构师SA (Solution Architect)。微软的这个分类是按照架构师专注的领域不同而划分的。

国内比较少会这么细分，企业很大程度希望架构师具有上述四种职能。当然如果一定要细分的话，我更倾向于从语言层面来分。

1、基础平台架构师：该职位职责，更多的是架构一个通用的，平台性的，与语言相关性较少的框架系统。ex：图片服务系统、分布式缓存、分布式存储、统一监控系统等等，很容易发现这些基础系统都不受制于开发语言，也就是说，用java开发的系统，和用c语言开发的系统，抑或php系统，如果需要使用分布式缓存，只需要调用各自语言的分布式缓存接口即可。 2、软件开发架构师：该职位职责，更多的是在某个特定领域具有比较深入的技术沉淀，从而根据特定环境制定特定的优秀软件架构系统。ex：JAVA架构师、DotNet架构师、LAPM架构师。

综述：无论哪种架构师，都无法完全脱离语言层面的东西，只能说根据职能不能，对语言层面依赖多少问题。 因此架构师几乎都是从程序员转变进阶过去。

回头再谈谈对某些话的一些肤浅想法。

“写程序，语言本身不重要，重要的是思想，语言都是相通的”。

假若你是技术大牛，那我很佩服你，因为你说这句话的时候，我想你应该在好些领域都精通了，至少也精通某些领域。所以依靠经验你确实可以忽略语言层面的东西。但是假如工作时间不长，这句话应该还是存在一些可质疑的地方。

举个例子，有人可以用php一个周完成一个网站。那你用c语言，或者汇编语言给我弄出来看看，当然这个例子有点极端。那就让你用java给我写吧（前提你不懂java，现学，但是你懂php）。就算你加班加点学完java ssi或者ssh弄出来了，但是刚学java的你、java程序质量又能有多高呢？不懂 JVM 工作原理、不懂 GC又如何写出高效程序；程序中总要用到hashMap吧、不知道hashMap底层数据结构，又如何能用好hashMap？（当然其他语言也有hashMap，原理大致差不多，但是如果你没有一定经验，你就怎么能确定java的hashMap和其他语言原理实现是一致的呢。而且确实也有各个语言实现不一致的情况，譬如java的内存自动GC，所以设计时候会略有不同）。就这个论题捎带多讲几句、对于c++而言、map底层为红黑树、hashmap为链接数组、不懂底层如何根据具体实际情况选择出效率最高的数据结构？越上层的语言对经验要求就越高，因为语言本身都会提供一整套完善的库让你调用，如果不熟悉，那么很抱歉，就算你是汇编高手，我想你来写java照样会是一团糟。犹记得，第一次写java程序时候，排序算法全部自己DIY，后来才知道，上层语言不像嵌入式，常用的工具类，基本都有，直接调用即可，而且性能一般说来要优于自己直接写。所以语言差别还是蛮大的。

吐槽这么多，总结下：如果你是基础平台构师级别语言确实不重要，因为架构技术都是相通的。如果你是开发实现、编码人员及特定语言平台架构、要想写出相对高质量的程序，和技术框架，还是有差别。所以我觉得语言选择于系统架构也相当重要，架构出来的东西还是要考虑如何能更好的实现才好。这就是为什么之前说的阿里系，京东派大规模转java架构体系原因。

所以对那些只是在YY着技术架构，光谈理论，不管实现的“技术大牛”，甚是难以理解。

再谈“青春饭”。简单谈下自己的一些理解吧。

我想如果足够热爱技术的话，为什么年龄到了三十，三十五就不能编程了？大家都知道国外很多大牛编程编到老（不过他们更多的是编码一些技术和经验要求很高的技术框架）。

那么“青春饭”，这又是为什么？

首先我们抗不过大环境。通俗的讲，中国软件行业国情决定了这个大气候环境。所以针对“青春饭”就不能着眼于国际来分析。那么问题来了。

假若当所有的人都认为到了一定年龄就不适合编码了，如果你还在编码那确实只能说你是个怪胎（因为你与国情不符）。

关于怪胎几点定义：1、还在编码，不能做技术管理或者技术架构（为公司创造更大价值)。2 、要价很高。 3、思想固化。4、缺乏激情。

这样就很容易理解计算机“青春饭”了。假若你工作七、八上十年了，你还是一个编码人员，管理不了团队，做不了技术架构之类的高级职务那么找工作确实困难。当然如果你要价和刚毕业的学生一样，那你技术上肯定还是很具优势。问题是，这可能么。再者，就算要价和刚毕业一样，你工作也缺乏了刚毕业学生的激情。最重要的一点是，对于刚毕业的学生，公司让他做什么，一般都会毫无怨言，自己找时间加班加点完成，你还能行么。如果不行，那么公司为什么要选你。还有一个就是，你都编码了那么久，还没达到一个相对较高的职位，我想更应该反思自己那么长的工作时间里，为什么没有成长到相之于编码更高的职级。其实原因很简单：要么你不适合这个行业，要么你不够努力。这样IT行业就被一些无聊之人给“青春饭”了。所以，我的观点是，计算机的“青春饭”是片面的。

（猜到大家对某些问题会有自己独特的见解，再次申明：所有文字仅代表个人观点，若与您观点不符，还请谅解）

重读百度百科之架构师：

架构师培养路程：

架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。总结架构师自我培养过程大致如下，仅供参考。 1、架构师胚胎( 程序员) 学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、 c++、uml、RUP、XML、socket通信( 通信协议)——学习搭建应用系统所必须的原材料。 2、架构师萌芽(高级 程序员) 学习 分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice( 研究生可以研究网络计算机、高性能并发处理等内容) 3、架构师幼苗(设计师) 应该在掌握上述基础之上，结合实际项目经验，透彻领会应用设计模式，内容包括设计模式( c++版本、java版本)、ejb设计模式、J2EE构架、UDDI、 软件设计模式等。在此期间，最好能够了解 软件工程在实际项目中的应用以及小组开发、 团队管理。 4、 软件架构师的正式成型在于机遇、个人努力和天赋 软件构架师其实是一种职位，但一个 程序员在充分掌握软构架师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理构架、如何不断的抽象和归纳自己的构架模式、如何深入行业成为能够胜任分析、构架为一体的精英人才这可不是每个人都能够遇上的馅饼…… 架构师应具能力： 一般来讲，系统架构师应该拥有以下几方面的能力： 1：具备 8 年以上 软件行业工作经验； 2：具备 4 年以上 C/S 或 B/S 体系结构 软件产品开发及架构和设计经验； 3：具备 3 年以上的 代码编写工作经验； 4：具备丰富的大中型开发项目的 总体规划、方案设计及技术队伍管理经验； 5：对相关的技术标准有深刻的认识，对软件工程标准规范有良好的把握； 6：对 .Net/JAVA 技术及整个解决方案有深刻的理解及熟练的应用，并且精通WebService/J2EE 架构和设计模式，并在此基础上设计产品框架； 7：具有 面向对象分析、设计、开发能力(OOA、OOD、OOP)，精通 UML 和 ROSE，熟练使用 Rational Rose、PowerDesigner 等工具进行设计开发； 8：精通大型 数据库如 Oracle、Sql Server 等的开发； 9：对 计算机系统、网络和安全、应用系统架构等有全面的认识，熟悉 项目管理理论，并有实践基础； 10：在应用系统开发 平台和项目管理上有深厚的基础，有大中型应用系统开发和实施的成功案例； 11：良好的 团队意识和协作精神，有较强的内外沟通能力。 架构师的隐形职责 1、为技术部门提供技术支持 2、在最需要的时刻去攻克最艰巨的技术壁垒 3、幕后 项目经理 4、业务部门与技术部门间的粘合剂 5、业务发展的催化剂

告一段落。

三、写在开头：

虽然一直有做笔记的习惯（可能记忆力太差缘故吧），但是之前没怎么考虑过写成文章分享出来。由于项目需要，近来倒是写了不少博文，算是一个开始吧。很早就想花点时间整理下自己对技术的一些肤浅理解和实践，让自己把学过的一些东西，整理成文保存下来。在分享出来的同时也可以和大家同进步。 架构是一个循序渐进的过程，没有永远优秀的架构，也不存在永不过时的架构，因此后续文章中，难免会随着自己知识面变广，而纠正前续文章瑕疵之处，还请见谅。 申明：由于笔者时间有限、再则水平原因、后续文章中难免出现错误、烦请大家理解。也欢迎各位指正建议。文章中参考的相关书籍资料由于太过分散，也不在文中一一标注出处。特别感谢众多技术大牛的参考书籍资料给予的巨大帮助和灵感。

四、回到正题，正式开篇：

先上图：大型高性能高并发网站系统从前端到后端的整体技术架构图：



针对上图，后续会出“系统原理分析架构专题”。上图中出现过的技术全部会详细讲解，当然由于是架构图就不便于列举太多技术理论及细节。所以也会将相关联的一系列理论及技术一一成文。ex：架构图中虽然没有明确提出分布式，但各处都存在分布式，所以后续专题针对这些就会去讲中心化与去中心化的优缺点。分布式弹性扩容的一致性hash原理，还有诸如经典的分布式原理CAP及NWR、以及SQL的实现之B树、Hash与NoSql实现之LSM树原理，还有像memcache VS redies内存实现原理等。只有懂了原理才能更清楚的理解如何架构选型。

到现在，本文差不多写写停停有大半个月时间了。足以见得把自己心里知道的，以及学习实践过的东西整理成文，是极具挑战的一件事情。当然还有许许多多的知识，在写的过程中需要不断新学习、实践。或者之前的理解本身就是错误的，则需要推翻重新验证，这些都需要花费很多时间。也希望自己能在后续的日子里，坚持、陆陆续续 （由于开发项目等原因，后续文章可能更多是利用业余时间撰写，时间跨度难免会比较随机） 把本次系统架构技术专列文章写下去，再次感谢各位朋友的关注与支持。

最后：本人不是专家，不是牛人；热爱自己的职业，写一些东西；权且当做给过往青春一个纪念。（2014.10.10）。