Java程序员的转型之路
我为什么要写这篇⽂章
武林中,"天下武功出少林"指各门各派的武功都与少林武学有⼀定的渊源,技术也是相同的道理,对于 Java 领域的应⽤⽽⾔,传统⾏业与互联⽹⾏业的技术都来⾃ J2SE 和 J2EE 的⽣态圈,但是两个⾏业的侧重点不同,传统⾏业侧重于严格的规范、复杂的流程、丰富的功能,因此或多或少的都会使⽤ J2EE 规范定义的技术,Appserver 是 J2EE 规范的完全实现,因此,传统⾏业的企业级软件开发基本都是部署在 Appserver 上的,这样可以重复利⽤ Appserver 提供的通⽤功能⽽节省开发和实现的⼯作量,⽽后者更注重互联⽹产品的⾮功能质量需求,通常包括:⾼可⽤、⾼性能、安全性、可伸缩、可扩展等,互联中最流⾏的⼀句话是:天线武功唯"快"⽽不破,充分看出互联⽹企业⾥程序性能的重要性,为了达到较好的性能,⾼度抽象的 J2EE 技术已经没法满⾜需求,因此互联⽹技术更倾向于在简单的 J2SE 上发展具有互联⽹特⾊的技术栈,重新定义互联⽹级的开发⼯具、平台和技术栈。
由于笔者从传统的外企转型到互联⽹已经有3个年头,近两年来⾯试了很多来⾃传统⾏业的同⾏们,笔者发现这些同⾏们都有意向⾛进处于风⼝的互联⽹,但是由于传统⾏业使⽤的技术栈与互联⽹有所不同,不知从哪⾥开始⼊⼿准备和提⾼,尽管他们有强烈的学习和提⾼的愿望,本⽂就是给这些想从传统⾏业跨⼊互联⽹的⼩伙伴们准备的⼀篇导向性⽂章,帮助读者了解互联⽹的技术栈、了解互联⽹的侧重点、
了解互联⽹的核⼼技术,并给出如何以传统⾏业的技术栈为基础快速掌握互联⽹的核⼼技术,其实,那只有⼀墙之隔,捅破那张窗户纸⼉,⼀切都豁然开朗。
这⾥需要再次澄清,我并不认为互联⽹⾏业的技术要⽐传统技术深奥多少,这些技术跑不出 J2SE 和 J2EE 的⽣态圈,只不过⾼度抽象的J2EE技术由于性能上的局限性⽽被互联⽹撇弃⽽已,但是不得不承认的是两个⾏业的侧重点不同,传统⾏业侧重于规范,流程,功能的复杂性以及正确性,⽽互联⽹更侧重于“快”,这⾥的“快”有两⽅⾯的意思,⼀个是产品运⾏效率要⾼,响应速度要快,另外⼀个是开发效率要快,响应市场需求要快。从另外⼀个侧⾯说,传统⾏业⼀般关注⼀个复杂系统的功能完善和丰富,⽽互联⽹企业更关注⼀个简单的垂直业务的⾮功能质量,例如:⾼性能,可⽤性,⾼并发,可扩展,可伸缩,安全性等,那么,⼀个从业⼈员从传统⾏业到互联⽹⾏业,你到底还有多少距离?
⼩伙伴们从哪⾥开始⼊⼿互联⽹
这两年来⾯试下来看到了⼀个普遍的现象,来⾃于传统⾏业的技术⼈员,他们⼤多数掌握的技能是 SSH,稍微资深⼀点的⼯程师对 J2EE 规范有所了解,他们仍然在使⽤ J2EE 规范的 EJB, JPA, JMS, JCA, JAAS 等技术,数据库基本上使⽤ Oracle,DB2,Sqlserver 等等。传统⾏业的开发⼈员基本实施“模块包揽制”,这得益于 J2EE 规范的完整性,以及 Appserver 提供了基本所有架构需要的功能,开发⼈员只需要将各个业务模块填⼊ J2EE 和 Appserver 提供给你的框架即可,因此,⼀个传统的开
发⼈员会包揽⼀个模块从前台到后台所有的⼯作,这包括:HTML, JS, CSS, EJB, JPA, SQL, PLSQL 等等。这些技术是不是⼀⽆是处,当然不是,反⽽是⾮常有价值的,那有了这些技术,我们是否可以⼀步跨⼊互联⽹,也不是,还需要以这些技术为基础,进⼀步扩展技术视野,对⽋缺的技术⼴度和深度进⾏不⾜。
下⾯就学习传统⾏业技术⼈员拥有哪些技术积累,下⼀步⼜如何补充⾃⼰的知识⾯,成为能够胜任互联⽹⾏业的优秀技术⼈员呢?
消息队列
在传统⾏业,相信你⼀定⽤过 JMS,作为 J2EE 规范的⼀部分,所有的 Aappserver(Weblogic、Websphere、Jboss 等)都有 JMS 的实现,那你⼀定知道 JMS 包含 Queue 和 Topic 两种 Subject,你也知道 Send/Receive 和 Publish/Subscribe 两种收发模式,那在互联⽹为什么就不⽤这些呢?
原因主要有两个,⼀个是商业的 Appserver 都是收费的,然⽽,互联⽹提供的产品是免费的,互联⽹使⽤的产品也多是免费的,另外⼀个原因就是这些 Appserver 的实现性能差,有测评显⽰ ActiveMQ ⽐ JbossMQ 速度要⾼出10倍,在某些应⽤场景下 ZeroMQ 的速度要⾼出⼀个数量级,可达到微妙级别的延迟,有兴趣可以参考 ZeroMQ 的性能测试页⾯。
除此之外,⼀些开源的 MQ 的实现针对互联⽹业务,提供了除 Queue 和 Topic 的⽀持,还有 partition,group,broker 等更复杂的消息模型,具体参考 Kafka, Kafka 的设计具有使⽤简单、功能丰富、⾼性能等优点,不但天⽣具有持久、分⽚、复制等功能,⽽且在使⽤上对开发者和运维的体验也很好。
那么如果你在传统⾏业掌握了 JMS 规范定义的消息队列技术,你只需要再往前⾛⼀步,请深⼊学习开源的 Kafka、RockitMQ、ActiveMQ、RabbitMQ、MemcacheQ、Redis、ZeroMQ、MSQ 等。
缓存
在传统⾏业,相信⼤家都⽤过 Oscache 和 Ehcache, 前者主要针对⽹页的缓存,后者主要针对数据库数据的缓存,通常可作为 Hibernate 的⼆级缓存,相信有些⼈还⽤过 Jboss Cache,这是⼀个分布式企业级可实时复制的 Cache,有些⼈在项⽬中也写了⾃⼰的缓存,甚⾄在⼀些项⽬中直接使⽤ Hashtable 作为缓存,其实这些缓存加速了特定场景下的数据访问,对你的项⽬成功起到了⾄关重要的作⽤。
但是互联⽹⾏业则从另外⼀个⾓度来使⽤缓存,主要应⽤场景有两个:第⼀,⼤量的数据需要集中保存,在服务的任意节点上可以访问缓存中的任意数据,也就是需要数据的中⼼存储,⽽且还要满⾜快速的查询需求的场景;第⼆,数据库读性能是有瓶颈的,廉价硬件机器上的单机 Mysql 读操作吞吐量
在 1000/s 左右,⼤量的读查询会压垮数据库,这需要使⽤缓存来抗住读流量,通常应⽤在有热点数据的场景。
从这两个应⽤场景来看,互联⽹⾏业更关⼼分布式缓存,那数据如何分布呢?很简单,Hash 或者⼀致性 Hash,所以,咱们可不可以先把Oscache 和 Ehcache 放⼀边,来研究⼀下 Redis,Memcache 或者淘宝的 Tair 呢?最简单的办法从 Redis 和 Memcache 的区别开始⼊⼿?
除了要学习分布式缓存,例如:Redis、Memcache 本⾝的功能和技术点外,最主要的要有缓存分⽚的思想,在互联⽹⾥⼤多数的热数据都是缓存在缓存服务中的,这需要⼤量的缓存服务器,单台机器是不能满⾜需求的,那缓存分⽚是⼀个⼤话题,缓存分⽚的实现⽅式⼀般有如下 3 种:
高级java程序员掌握技能1. 通过代理层实现,例如 Codis,在代理层实现数据的路由,对应⽤层透明。
2. 客户端分⽚,可参考我的开源项⽬ ,实现简单、使⽤简单、⽀持分⽚、复制、失效转移等功能。
3. 缓存服务器⽀持的⾼可⽤模式,例如:Redis 3.x、Sentinel 等。
服务框架
在传统⾏业,相信⼤家都使⽤ EJB 和 Webservice 来提供服务的导出和导⼊,有些个别传统⾏业不⽤ APP 服务器,仅仅使⽤ JDK 的
RMI 来导出和导⼊服务,但是为什么互联⽹偏偏不喜欢这些技术呢?Webservice 使⽤重量级的 SOAP 协议,臃肿的 XML 满世界都是,性能上的去吗? 那互联⽹⽤什么,互联⽹使⽤轻量级的 RPC 框架和 RESTful 服务,前者使⽤轻量级的序列化框架,例如:Google 的ProtoBuffer, 还有 Hessian 和 Burlap 等序列化协议,后者则使⽤简单的 HTTP 协议,前者适合在内⽹做⾼性能的服务调⽤,⽽后者适合异构平台的服务调⽤,例如: 跨语⾔,跨防⽕墙,前后台之间等。RPC 远程调⽤请参考阿⾥的 Dubbo 框架和 Twitter 的 Finagle 框架,⾄于 Rest 框架参请考 Spring Web MVC,Spring Boot、Jersey,Apache CXF 等。
在互联⽹的世界⾥,⼏乎所有的公司都实现了服务化,服务化导致的问题就是⼀致性问题,如何解决⾼并发系统的⼀致性呢?使⽤两阶段提交协议、三阶段提交协议、TCC?还是遵循 ACID 原理、CAP 原理、BASE 原理?
最近微服务变得越来越流⾏,微服务实际上是服务化的⼀个延续,是更细致化的服务化的架构,微服务的服务框架的代表是 Spring Cloud,它与 Netflix 集成,提供了限流、熔断、仓壁隔离、失效转移等为服务化中必不可少的⾼级特性,⼤家可以到官⽹⽂档进⼀步学习Spring Cloud 相关技术。
数据库
在传统⾏业,⼤多数⼈开发⼈员都使⽤ Oracle, DB2, Sqlserver 数据库,其实,从功能和性能上来讲,
他们都不亚于 Mysql, 甚⾄⽐Mysql 更优秀,但是 Mysql 是免费的,这使得 Mysql 得到互联⽹⾏业的青睐。
那么我们分析下,传统⾏业的⼈员在数据库⽅⾯⽋缺什么吗?⾸先,Oracle 和 Mysql 都使⽤ B+ 树索引,原理相同,使⽤⽅法相同;Oracle ⽀持⾏级锁,Mysql Innodb 同样⽀持⾏级锁;Oracle Dataguard ⽀持数据复制,Mysql 也⽀持数据复制,但是Mysql的复制模式更灵活,并且⽀持主主配置。前⾯这些都是⼤同⼩异,如果你理解了相应的 Oracle 技术,你⽤很少的时间就可以掌握 Mysql 的相关技术。但是不同点是,Oracle 虽然⽀持集,通过增加服务节点的⽅式可以增加服务性能,但是集的节点数量是有限的,并且数据存储是共享的,所以扩容基本采⽤垂直⽅式,然⽽使⽤ Mysql 则采⽤⽔平扩展,也就是需要进⾏⼿⼯的分区分表,对数据进⾏分⽽治之,以满⾜⽇益增长的读写压⼒以及数据存储压⼒。因此,如果想向互联⽹转⾏,⼀定要学好 Mysql,推荐阅读《⾼性能 Mysql》,这本书是必读的书籍,⽽且推荐每⼀个应⽤开发⼈员都要通读全书,⽽不是仅仅读其中与应⽤相关的那部分。
在互联⽹⾏业⾥⾯对性能追求到达了极致,因此会要求开发⼈员对数据库原理有所了解,其中最重要的部分就是索引。
负载均衡
刚才谈到,⾼并发系统,压⼒⼭⼤的时候怎么办?思想只有⼀个分⽽治之( divide-and-conquer)。因此,负载均衡则⾮常重要,传统⾏业以销售产品为盈利模式,因此,⼤多数项⽬在需要负载均衡的时候,多使⽤ F5 硬件负载均衡。
实际上传统的 J2EE 规范的 EJB 也可以分布式发布,通过 JNDI 的集成,也可以进⾏⼀定程度的负载均衡,但是这个负载均衡显得太重量级,⽤起来⾮常的不⽅便,效率也很低,并且和APP服务器绑定。
那么互联⽹呢?多采⽤软负载均衡,你必须了解 LVS,nginx, Apache, Varnish, Haproxy 等七层和三四层负载均衡原理和产品。
JVM
另外,在互联⽹⾏业做 Java 开发,⼀定要对 JVM 有所了解,并且进⾏深⼊的研究,例如:GC,类加载,Hotspot 编译器,多线程、并发和锁,IO 和 NIO 等。推荐阅读《深⼊理解 Java 虚拟机 ++JVM ⾼级特性与最佳实践》,《深⼊理解 Java7》,《Java Concurrency In Practice》,《Pro Java 7 NIO.2》,《Java Performance》等⼀系列深层次的JVM相关数据,最好能阅读《The Java® Language Specification》和《The Java® Virtual Machine Specification》两本龙书
⼤数据与云计算
作为⼀个IT从业⼈员,⼀定要跟上技术潮流,像云计算,⼤数据,CAP, BASE, 选主算法等概念不得不去了解,对于热点技术不得不研究,例如: Hadoop, Hbase, Zookeeper, Openstack, Dooker, Kafka, Storm 等。
对于⼤数据技术推荐阅读Google三⼤论⽂,Mapreduce, GFS和BigTable,这三篇论⽂是⼤数据处理的⿐祖型论⽂,最核⼼的分布式存储、分布式处理、⼤⽂件的⾼效存储等技术都在这⾥,⼤数据⿐祖的三⼤论⽂
性能评估和容量估算
如果你决定要来互联⽹⼀显⾝⼿,你必须学会性能评估和容量估算,这包括对前端机、缓存、消息队列、数据库等各个性能指标的估算,例如:吞吞量,响应时间,内存,CPU,IO,⽹络 IO 等。
为了确保架构设计的合理性,性能和容量评估是在架构设计初期完成的,⽤来证明架构⽅案可⾏,但是在项⽬实施中和实施后,还需要对项⽬的进⾏压测,来证明项⽬按照既定的⽬标⽽推荐和完成,关于性能测试的⽅法论和设计流程,我将会在后续⽂章中介绍给读者。
互联⽹架构⽅法论
在互联⽹⾏业⾥,处理⼤规模⾼并发的⽤户请求的核⼼思想只有⼀个,那就是“分⽽治之”,因此,通常
业务被拆分为多个职责单⼀的服务,在某⼀个单服务⾥,业务逻辑并不复杂,但是对⾮功能质量需求的要求较⾼,这通常表现在性能、可⽤性等⽅⾯,因此互联⽹的架构设计中⾸要考虑的是⾮功能质量,这和传统⾏业注重功能和业务流程的情况有所不同,对于互联⽹⾏业中,架构设计的案例,来了解互联⽹业务的架构设计的风格和思路。
技术攻关和线上应急
在互联⽹企业⾥,⼤多数产品都是针对⽤户端的,⽤户端的产品的特点是拥有海量的⽤户、产品要能够处理海量⽤户产⽣的⼤规模⾼并发的⽤户请求,因此会对产品的可⽤性⽐较敏感,在这种环境下,技术攻关和线上应急显得尤为重要,例如:如何解决线上线程卡死问题、如何解决 OOM 问题、如何解决服务超时问题等。
向这⾥看你会豁然开朗
希望这篇⽂章能够帮助更多的传统⾏业的从业⼈员转⼊互联⽹,在互联⽹的⼤舞台上展现你的才能,最后,附赠⼀张笔者在互联⽹⾏业⾥通过⾯试识别⼈才的《Java 技能图谱》,⼤家可以根据其中的思维导图来深⼊学习各项知识点,每个知识点都需要系统的学习,或者看⼀本书或者查询相关的资料,切记要积累知识的⼴度的同事也要有⼀定的深度。
最后给⼤家推荐⼀个⼝碑不错的Java聚集地【】,这⾥有很多的⽼前辈学习技巧,学习⼼得,⾯试技巧,职场经历等分享,更为⼤家精⼼准备了零基础⼊门资料,实战项⽬资料,每天都有程序员定时讲解java技术,分享⼀些学习的⽅法和需要留意的⼩细节
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论