感谢朋友支持本博客,欢迎共同探讨交流,由于能力和时间有限,错误之处在所难免,欢迎指正!
如有转载,请保留源作者博客信息。
如需交流,欢迎大家博客留言。
先上图:大型高性能高并发网站系统从前端到后端的整体技术架构图:
怀着求知、进取的心开启本文,望与大家共进步。
细想一下,自己用过的语言应该也不算少。简述之、从最底层开始,画过电路板(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一人难求,所以注定python国内短期内没法太火。不过在google等大牌的大力推崇下python发展势头还是很迅猛。不过python效率比java要低,而且是小众语言,后续发展有待验证。最后顺带列出捣鼓过的前端语言:html、css、javascript、jquery(DIY 过 js分页插件)。前端语言似乎没太要说的必要,大部分公司用的都差不多。
说了这么多总结一下:
使用时间排序:c > python > java > 其他
喜欢程序排序:java > 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、架构师胚胎(
程序员)
2、架构师萌芽(高级
程序员)
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 等的开发;
10:在应用系统开发
平台和项目管理上有深厚的基础,有大中型应用系统开发和实施的成功案例;
11:良好的
团队意识和协作精神,有较强的内外沟通能力。
架构师的隐形职责
1、为技术部门提供技术支持
2、在最需要的时刻去攻克最艰巨的技术壁垒
3、幕后
项目经理
4、业务部门与技术部门间的粘合剂
5、业务发展的催化剂
|
告一段落。
三、写在前面:
虽然一直有做笔记的习惯(可能记忆力太差缘故吧),但是之前没怎么考虑过写成文章分享出来。由于项目需要,近来倒是写了不少博文,算是一个开始吧。很早就想花点时间整理下自己对技术的一些肤浅理解和实践,让自己把学过的一些东西,整理成文保存下来。在分享出来的同时也可以和大家同进步。
架构是一个循序渐进的过程,没有永远优秀的架构,也不存在永不过时的架构,因此后续文章中,难免会随着自己知识面变广,而纠正前续文章瑕疵之处,还请见谅。
申明:由于笔者时间有限、再则水平原因、后续文章中难免出现错误、烦请大家理解。也欢迎各位指正建议。文章中参考的相关书籍资料由于太过分散,也不在文中一一标注出处。特别感谢众多技术大牛的参考书籍资料给予的巨大帮助和灵感。
四、回到正题,正式开篇:
先上图:大型高性能高并发网站系统从前端到后端的整体技术架构图:
针对上图,后续会出“系统原理分析架构专题”。上图中出现过的技术全部会详细讲解,当然由于是架构图就不便于列举太多技术理论及细节。所以也会将相关联的一系列理论及技术一一成文。ex:架构图中虽然没有明确提出分布式,但各处都存在分布式,所以后续专题针对这些就会去讲中心化与去中心化的优缺点。分布式弹性扩容的一致性hash原理,还有诸如经典的分布式原理CAP及NWR、以及SQL的实现之B树、Hash与NoSql实现之LSM树原理,还有像memcache VS redies内存实现原理等。只有懂了原理才能更清楚的理解如何架构选型。
到现在,本文差不多写写停停有大半个月时间了。足以见得把自己心里知道的,以及学习实践过的东西整理成文,是极具挑战的一件事情。当然还有许许多多的知识,在写的过程中需要不断新学习、实践。或者之前的理解本身就是错误的,则需要推翻重新验证,这些都需要花费很多时间。也希望自己能在后续的日子里,坚持、陆陆续续
(由于开发项目等原因,后续文章可能更多是利用业余时间撰写,时间跨度难免会比较随机)
把本次系统架构技术专列文章写下去,再次感谢各位朋友的关注与支持。
最后:本人不是专家,不是牛人;热爱自己的职业,写一些东西;权且当做给过往青春一个纪念。(2014.10.10)。