首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

语言栈转型经验谈

近一年都在做语言栈的转型,也注意到周围很多公司都在做相似的事情,大概的路径是 Python -> Go -> Java,转型的起因也是有诸多的因素,像 Python 这种开发速度快,执行相对慢的语言更适合中小型项目,加上国内语言生态不够成熟,项目做大了会发现大家一刀切的转到其它语言上,当然这些说的是在做 web 后端方向上,Python 在数据分析和人工智能方向上还是势头很猛的。Go 可能还是因为它能承载的并发更高,性能更好而逐渐流行起来。在并发模型上 Java 原生 API 使用上确实做得不好驾驭,Go 则要相对好用很多。还有在某些垂直领域上,Java 的生态已经很成熟,其它语言栈上则需要自己造轮子,相应对于开发人员的水平要求就会低很多了。

01

CgLib ,NCgLib 和AOP (之一)

广大关心编程前沿的程序员已经对AOP的感念耳熟能详了。无论是基于.NET的实现还是基于Java的实现都有很多开源的项目可供参考。 对AOP不了解的读者可以到我得AOP专栏,熟悉一下AOP的基本概念。     回顾AOP的历史可以看出,AOP并不是最近几年才冒出的“新”概念,据说历史可以追溯到施乐公司的一个实验室的项目。        从汇编语言,面向过程的编程,在到现在被广泛接受的OOP的编程思想,人们逐步抽象出对现实世界的描述。这每一步的进步,都使得我们对大规模的软件编程更容易控制和实现。     那么为什么到了现在AOP才受到业界广泛关注呢?     一方面OOP的编程思想相对成熟,也逐步显露出了其不能有效解决的领域,这部分需要新的思想来填充。另一方面就是程序语言的进步。     大家知道AOP的特点之一是Interception,就是拦截。比如在方法执行前,执行中,执行后动态插入一些额外的方法,典型的就是日志,权限和事务控制。     在基于虚拟机java 和 CLR 的.net 出现以前实现方法拦截,几乎不可能。 单单从Interception上说,珊瑚虫  和 木子版本的 QQ 就是一个 具有AOP特性的实现。大家有兴趣可以了解一下 珊瑚虫 或者 木子 版本的QQ的实现方式,可以说是呕心沥血,经历了无数次的重新启动和汇编测试,才实现了对QQ相关方法的拦截。     因为无论是java的字节代码,还是.net的伪编译,他们生成的都不是最终的机器代码,而是平台无关的代码,这些代码在具体执行的时候还需要翻译成机器代码才可以执行。中间语言的出现使我们对执行前的代码有了更多的控制。     正因为如此AOP的理论有了实现的可能,这个时候出现可谓水到渠成。     一般来讲AOP的实现有3种途径:     1 在编译成中间代码前就让代码具有AOP的特性,比如AspectWikez;     2 使用语言特性,从设计方法出发,实现AOP,比如基于Java 的动态代理实现AOP。(见我得南宁系列文章);     3 在中间代码运行时,动态修改中间代码,使其具有AOP特性。     上面3种方法的有缺点我认为有几下几点:     采用的一种方法,一般需要编译器的扩充支持,如同C编译器的出现代替汇编一样,需要长时间的验证其稳定性和效率。另外对于最终开发人员来说也需要学习这些编译器,或者新的语法指令完成这些功能,当然功能也最强大。     第2种方法,我认为是一种轻量级别的实现,比如Nanning 和 DynAOP 等,一般这样的实现需要在设计上下功夫。比如需要基于接口编程。对于已有的项目来说,改动量非常大。     第3种方法,介于1,2种方法之间。采用第3种方法实现AOP,不需要每个类都有一个接口,也没有什么编译器的更改。他的缺点是需要高超的编程技巧。正因为如此,才有很多项目用第3种方法包装后,给最终开发人员使用比如:Spring。     实际上Spring 的AOP实现种第1,2种方法都采用了。     我认为目前的项目种,大规模的采用AOP还不适合,一方面AOP还在发展之中,另一方面支持AOP的框架还没有被广泛的接受。     正因为如此我们不妨直接操作中间代码,在项目的一些关键地方实现一些AOP的特性。     那在Java的世界中可以用cglib,Javassist 等     在.net的世界中可以用ncglib。     下文我们来给出一些代码例子。     (待续)

04

Elasticsearch 概述

Google,百度类的网站搜索,它们都是根据网页中的关键字生成索引,我们在搜索的时 候输入关键字,它们会将该关键字即索引匹配到的所有网页返回;还有常见的项目中应用日志的搜索等等。对于这些非结构化的数据文本,关系型数据库搜索不是能很好的支持。 一般传统数据库,全文检索都实现的很鸡肋,因为一般也没人用数据库存文本字段。进行全文检索需要扫描整个表,如果数据量大的话即使对 SQL 的语法优化,也收效甚微。建 立了索引,但是维护起来也很麻烦,对于 insert 和 update 操作都会重新构建索引。 基于以上原因可以分析得出,在一些生产环境中,使用常规的搜索方式,性能是非常差 的:

01

架构师之路--谈架构师的基本素养和[干货]日志处理

由于前两篇文章的关系,最近收到很多朋友的反馈和私信,谈如何成长为一个架构师的问题。在这之前我很少有时间去考虑这个问题,因为我总有做不完的事儿:看不完的书,解决不完的问题,干不完的活儿……  不是我干活儿慢,实际情况恰恰相反。但是我总是能给自己找很多的事情。我的桌面上有好几个txt,里面记录着各个方面要做的事情,看书过程中发现的问题等等。去年有一段时间很闲,我每天干着公司里的活儿,自己创着业,一天还要写一两篇专利,还是感觉很闲。其实就是想的少,做的不够细。而一个人能给自己找到多少要做的事情才是一个人真正的

03
领券