集团站切换校区

验证码已发送,请查收短信

复制成功
微信号:togogoi
添加微信好友, 详细了解课程
已复制成功,如果自动跳转微信失败,请前往微信添加好友
打开微信
图标

业界新闻

当前位置:首页 > >业界新闻 > >

Java领域从传统行业向互联网转型你必须知道的那些事儿

发布时间: 2017-06-26 15:00:30

武林中,"天下武功出少林"指各门各派的武功都与少林武学有一定的渊源,技术也是相同的道理,对于Java领域的应用而言,传统行业与互联网行业的技术都来自J2SE和J2EE的生态圈,但是两个行业的侧重点不同,传统行业侧重于严格的规范、复杂的流程、丰富的功能,因此或多或少的都会使用J2EE规范定义的技术,Appserver是J2EE规范的完全实现,因此,传统行业的企业级软件开发基本都是部署在Appserver上的,这样可以重复利用Appserver提供的通用功能而节省开发和实现的工作量,而后者更注重互联网产品的非功能质量需求,通常包括高可用、高性能、安全性、可伸缩、可扩展等,“天下武功唯快而不破”,充分看出互联网企业里程序性能的重要性,为了达到较好的性能,高度抽象的J2EE技术已经没法满足需求,因此互联网技术更倾向于在简单的J2SE上发展具有互联网特色的技术栈,重新定义互联网级的开发工具、平台和技术栈。

本文就是给这些想从传统行业跨入互联网的小伙伴们准备的一篇导向性文章,帮助各位了解互联网的技术栈、互联网的侧重点、互联网的核心技术,并给出如何以传统行业的技术栈为基础快速掌握互联网的核心技术。

这里需要再次澄清,小编并不认为互联网行业的技术要比传统技术深奥多少,这些技术跑不出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都有JMS的实现,那你一定知道JMS包含Queue和Topic两种Subject,你也知道Send/Receive和Publish/Subscribe两种收发模式,那在互联网为什么就不用这些呢?原因主要有两个,一个是商业的Appserver都是收费的,然而,互联网提供的产品是免费的,互联网使用的产品也多是免费的,另外一个原因就是这些Appserver的实现性能差,有测评显示ActiveMQ比JbossMQ速度要高出10倍,在某些应用场景下ZeroMQ的速度要高出一个数量级,可达到微妙级别的延迟。除此之外,一些开源的MQ的实现针对互联网业务,提供了除Queue和Topic的支持,还有partition、group、broker等更复杂的消息模型,具体参考Kafka。 Kafka的设计具有使用简单、功能丰富、高性能等优点,不但天生具有持久、分片、复制等功能,而且在使用上对开发者和运维的体验也很好。那么如果你在传统行业掌握了JMS规范定义的消息队列技术,你只需要再往前走一步,请深入学习开源的Kafka、RockitMQ、ActiveMQ、RabbitMQ、ZeroMQ、MSQ等。

缓存

在传统行业,相信大家都用过Oscache和Ehcache, 前者主要针对网页的缓存,后者主要针对数据库数据的缓存,通常可作为Hibernate的二级缓存,相信有些人还用过Jboss Cache,这是一个分布式企业级可实时复制的Cache,有些人在项目中也写了自己的缓存,甚至在一些项目中直接使用Hashtable作为缓存,其实这些缓存加速了特定场景下的数据访问,对你的项目成功起到了至关重要的作用。但是互联网行业则从另外一个角度来使用缓存,主要应用场景有两个:第一,大量的数据需要集中保存,在服务的任意节点上可以访问缓存中的任意数据,也就是需要数据的中心存储,而且还要满足快速的查询需求的场景;第二,数据库读性能是有瓶颈的,廉价硬件机器上的单机Mysql读操作吞吐量在1000/s左右,大量的读查询会压垮数据库,这需要使用缓存来抗住读流量,通常应用在有热点数据的场景。从这两个应用场景来看,互联网行业更关心分布式缓存,那数据如何分布呢?很简单,Hash或者一致性Hash,所以,咱们可不可以先把Oscache和Ehcache放一边,来研究一下Redis,Memcache或者淘宝的Tair呢?最简单的办法从Redis和Memcache的区别开始入手?除了要学习分布式缓存,例如Redis、Memcache本身的功能和技术点外,最主要的要有缓存分片的思想,在互联网里大多数的热数据都是缓存在缓存服务中的,这需要大量的缓存服务器,单台机器是不能满足需求的,缓存分片是一个大话题,就不在这里深入讨论了。

服务框架

在传统行业,相信大家都使用EJB和Webservice来提供服务的导出和导入,有些个别传统行业不用APP服务器,仅仅使用JDK的RMI来导出和导入服务,但是为什么互联网偏偏不喜欢这些技术呢?Webservice使用重量级的SOAP协议,臃肿的XML满世界都是,性能上的去吗? 那互联网用什么,互联网使用轻量级的RPC框架和RESTful服务,前者使用轻量级的序列化框架,例如:Google的ProtoBuffer, 还有Hessian和Burlap等序列化协议,后者则使用简单的HTTP协议,前者适合在内网做高性能的服务调用,而后者适合异构平台的服务调用,例如跨语言、跨防火墙、前后台之间等。在互联网的世界里,几乎所有的公司都实现了服务化,服务化导致的问题就是一致性问题,如何解决高并发系统的一致性呢?使用两阶段提交协议、三阶段提交协议、TCC?还是遵循ACID原理、CAP原理、BASE原理?如果我们保证的是最终一致性模型,我们都有哪些模式可以应用。最近微服务变得越来越流行,微服务实际上是服务化的一个延续,是更细致化的服务化的架构,微服务的服务框架的代表是Spring Cloud,它与Netflix集成,提供了限流、熔断、仓壁隔离、失效转移等为服务化中必不可少的高级特性。

数据库

在传统行业,大多数人开发人员都使用Oracle、DB2、Sqlserver数据库,其实,从功能和性能上来讲,他们都不亚于Mysql, 甚至比Mysql更优秀,但是Mysql是免费的,这使得Mysql得到互联网行业的青睐。

那么我们分析下,传统行业的人员在数据库方面欠缺什么吗?首先,Oracle和Mysql都使用B+树索引,原理相同,使用方法相同;Oracle支持行级锁,Mysql Innodb同样支持行级锁;Oracle Dataguard支持数据复制,Mysql也支持数据复制,但是Mysql的复制模式更灵活,并且支持主主配置。前面这些都是大同小异,如果你理解了相应的Oracle技术,你用很少的时间就可以掌握Mysql的相关技术。但是不同点是,Oracle虽然支持集群,通过增加服务节点的方式可以增加服务性能,但是集群的节点数量是有限的,并且数据存储是共享的,所以扩容基本采用垂直方式,然而使用Mysql则采用水平扩展,也就是需要进行手工的分区分表,对数据进行分而治之,以满足日益增长的读写压力以及数据存储压力。因此,如果想向互联网转行,一定要学好Mysql。在互联网行业里面对性能追求到达了极致,因此会要求开发人员对数据库原理有所了解,其中最重要的部分就是索引。

负载均衡

刚才谈到,高并发系统,压力山大的时候怎么办?思想只有一个分而治之( divide-and-conquer)。因此,负载均衡则非常重要,传统行业以销售产品为盈利模式,因此,大多数项目在需要负载均衡的时候,多使用F5硬件负载均衡。实际上传统的J2EE规范的EJB也可以分布式发布,通过JNDI的集成,也可以进行一定程度的负载均衡,但是这个负载均衡显得太重量级,用起来非常的不方便,效率也很低,并且和APP服务器绑定。那么互联网呢?多采用软负载均衡,你必须了解LVS、nginx、Apache、Varnish、Haproxy等七层和三四层负载均衡原理和产品。

性能评估和容量估算

如果你决定要来互联网一显身手,你必须学会性能评估和容量估算,这包括对前端机、缓存、消息队列、数据库等各个性能指标的估算,例如:吞吞量,响应时间,内存,CPU,IO,网络IO等。为了确保架构设计的合理性,性能和容量评估是在架构设计初期完成的,用来证明架构方案可行,但是在项目实施中和实施后,还需要对项目的进行压测,来证明项目按照既定的目标而推荐和完成。


希望这篇文章能够帮助更多的传统行业的从业人员转入互联网,在互联网的大舞台上展现你的才能。


上一篇: 腾科快讯-历数谷歌Go 1.9语言中的新鲜特性

下一篇: 腾科快讯-值得你加以了解的五款Material Web设计框架

在线咨询 ×

您好,请问有什么可以帮您?我们将竭诚提供最优质服务!