由于高可用架构群每天有大量技术讨论,同时在架构领域也不断有新的技术及思想产生,因此架构君摘取部分值得一读的讨论及资源,供关心架构领域的同行参考。小编不生产文章,小编只是文字的搬运工。
码农界有个广为人知的笑话
女神:你能让这个论坛的人都吵起来,我今晚就跟你走。
程序员:PHP是最好的语言!
某论坛真的就炸锅了,各种吵架……
女神:服了你了,我们走吧,你想干啥都行。
程序员:今天不行,我一定要说服他们,PHP必须是最好的语言……
今天的日报也是由一个典型的争议问题开始
调查:有哪家之前不是用java开发的,后来转java的?为什么转?
语言讨论
淘宝就是经典案例啊
还有京东[呲牙]
还有twitter
亚马逊也是,我进去第一个项目就是c++ migrate到java
携程也部分服务开始用java了吧
Twitter的Heron,C++,这是理性回归吗
Java之争
C和C++在基础服务还是可以的,比如想存储什么的,偏上层一点的 真不如Java好
第一.net等闭源的语言,访问量上来,很多问题没法跟到最里面来定位问题,所以好多电商后期换java, 第二Java人好找,开发效率高。以前一直搞py和cpp,看不上java,后来又不得不搞Java了
反正我对语言没有偏好,什么合适就用什么,上次遇到个写go的,说实在受不了Java的try catch,太啰嗦了,然后我说go的error从底层传到最上层,每层要写if,java只需要扔一个runtime出来,然后在最外层的框架层处理,他就不说话了
Java做业务也比go强一点,java代码可以做到业务方根本看不到任何关于db的东西,比如连接多库,transaction控制,但go就比较难
Java让我这种资质平庸的人也能写写代码[呲牙]
Java有强大的人才库和企业持续投入支持,这就是最大的优势啊
Java的整个生态更完善些,go的依赖管理就把人搞郁闷,go适合于追求自由的程序员,无拘无束
Java对语言内部了解比较深的也不多的,这一块感觉还是挺缺的
我倒是觉得现在必须要考虑一个语言,很容易找到人接盘蛮重要的。
有时候人跑了,一个公司然后这个语言就没人玩得动,招人也找不到,就悲剧了。
那后端真正的api还得从Java、c++、go等里面选。
Golang
C/c++程序员对go的认同度更高些
.NET 转 Java,C/C++ 转 go,基本这趋势
chrome等基础软件还是得c cpp. 美国这类软件比较多,国内基础软件比较少
并且谷歌这几年名声不太好,用go也顾虑颇多。
Go 想保持简单这是好事,但有些东西用起来 还是有点不太够
选go或者node 甚至lua一般就是业务轻 高性能
其实我有个感觉,就是推崇go的都是以技术为出发点,热爱编程,享受编程带来的乐趣,打开vim,啪啪啪的就可以享受编程了,但是java更更像是从事情本身为出发点,一堆的规则,力求避免程序员人为犯错,关心怎么样一起协作,怎么样管理依赖等等
C/C++
go 目前应用主要还是服务端,C/C++ 在桌面应用还是强,不过现在真没多少桌面应用了
chrome把cpp模板的用的淋漓尽致,能往里跟的动,也是需要一定力气的,基础软件主要出于性能考虑吧,不好用java
c++招有经验的越来越难了,学习曲线长
以前做山寨机业务代码全部是c,不过设计相当不错,用c实现了面向对象方法
游戏服务端应该用c++写业务逻辑的比较多。
我也见过用c实现面向对象的,整个工程全是结构体和函数指针
当时我是帮他们解bug,真是看得想吐,其实代码结构很清楚,只是一堆void*指针
Python
每个语言都有它的优点,应该共存的,流行的语言不一定语法比另一个好,流行有很多其他因素,比如ruby,lua比Python语法更好,但是没py流行
Lua
Lua火在游戏届
Lua用来做胶水语言,也挺好的。
nginx+lua做业务现在也很多
agentzh一直在做Lua的生态,推他的openresty
上一家公司很多后端服务都是用nginx+lua做api
之前好像看到又拍云也在往nginx+lua上转
脚本语言其实不要有经验,边学边用就行了,一般人都没什么问题。很难的服务端高并发一些奇奇怪怪的问题,需要一两个源码级的够了,没数据量也碰不到
是的,就是前端和db中间的
lua一般不写业务太复杂的服务 我觉得,要说另一种语言也就是用c来写一些模块扩展
是的,业务不复杂,性能要求高。比较适合用lua
当然 由于lua对nginx的依赖 也是个制约
lua+nginx可以做做代理层面的扩展,比如统一身份认证啥的,类似于api-gateway, 写具体的业务逻辑还是比较费劲吧?
目前看到Lua除游戏外的,就做这块,和nginx配合使用。
lua游戏那边主要是云风,nginx+lua这边主要是agentzh。感觉就他们两个的博文较多
lua需要c来写模块,做些复杂点的逻辑,更复杂的需要后端服务提供api。那后端服务又得选语言。
用lua纯实现业务逻辑还是有不少坑的,版本越高越慢
业务复杂后用lua确实不太好维护
用Lua写业务,感觉是不需要用rdbms的节奏
觉得lua写业务恐怖的,那是因为你们没见过用c写业务的公司[坏笑]
游戏里面用lua是有别的原因
这个当然了,lua在游戏方面应用的时间非常久了
Scala
以Go语言的开发效率能不能代替Erlang呢。
我还是比较喜欢能以开放态度,什么语言都接受的公司,
并发编程的话,我们的路线是Erlang转向Scala,但是Scala学习曲线太高了
框架讨论
说到Scala之后,引起新的问题
我们这边一个老团队开新业务,内部招人,别的团队的人第一句话都是问:还要继续用 scala 吗“?写scala 的人,一个转产品,一个转 leader,没剩下几个了
L: 像以前在亚马逊,服务之间约定好接口,我管你用什么语言,只要满足你对于服务质量的promise就行
T: 问题是,小公司里,如果一个服务没有满足 promise 你怎么办?如果你用了奇怪的语言或者框架,别的人都没法帮忙
T: 我刚帮着折腾了两个月的 akka 和 play 。。。akka 里解决的一个大问题,居然是 log actor 的性能不行,导致内存堆积;这种框架,不碰到坑就天下太平,万一碰到坑,你就只好自求多福
L:小公司从组织架构到基础工具都做不到,所以也只好尽量减少语言栈
G: 看豌豆荚的akka分享,感觉还不错啊
T: 这两天在折腾 sbt 和 maven 的配合问题。。。一把辛酸泪,公司里有两个二进制repo,伤不起;总之一句话,在公司里或团队里,保持技术栈的简单可靠,是一件功德无量的时期。我正在这边推 spring boot,套上一个简单的 http rpc,把其它乱七八糟的底层依赖全干掉,上层业务逻辑爱用啥用啥,基础设施保持统一就行。
L: 之前有人想引入c++,坚决抵制住了
Y: 不搞spark就别scala了
F: 我还是spring webmvc
W: 成功从 Play framework 的 Scala + SBT 栈换到了 Spring boot 的 Java + Maven
S: springboot起码解决了内嵌tomcat的问题?
T: spring boot 解决了“该怎么用 java 代码做这种事情” 的选择问题
Y: sbt 不是Springboot
T: sbt 是 simple build tool
F: scala 可以用 gradle,还是挺舒服的
Y: 我们也刚改了SpringBoot
S: 但是我感觉springboot还要runtime读取jar包 好土,jar包套jar包,我们最近看的 start.spring.org, 里面的各项东西都比较靠谱
W: sbt里引用国内第三方的包时简直要哭死,比如各类SDK(支付、推送、短信等等)
J: 我觉得scala推广最大的阻力其实就是sbt。不知道为啥scala的创始人不好好的用gradle/maven。这可能是java最开始的时候没有内置依赖管理导致的。go如果不赶紧解决依赖管理问题,等社区里出来几个依赖管理的解决方案,就又像java一样开始分裂了。
T: 现在总结出来,凡是版本号在 0.x的,或者最近几个版本之间兼容性差的,都不能用,sbt两条都符合
Z: 哈,上次带josh四处求爷爷告奶奶展示spring boot demo,这下从群里找到组织了[表情] 居然这么多人用的。。
josh上次在沪江分享过
先去脑补一下spring boot
直接springmvc, so easy
业务系统用java 这么呆的语言都成这个样子了,真不知道如果换成scala 会变成啥
现在喜欢上了node.js
想进一步同群专家进一步交流高可用架构,并探讨什么是最好的高可用架构语言的,可回复arch申请进群。由于主群人员长期处于满员状态,为了让更多同行可以参与架构交流,近期开放了一个新的高可用架构群(待冠名),很多排队的朋友喜大普奔,虽然已经快满,不过依然还可以申请加入。
本文编辑TimYang。想阅读更多架构方面内容,可以通过搜索“ArchNotes”或长按下面图片,关注“高可用架构”公众号,获取通往架构师之路的宝贵经验。 转载请注明来自“高可用架构(ArchNotes)”微信公众号。