Go语言走向企业应用还需要什么?

15-02-12 banq
                   

Go语言走向企业应用需要一套成熟的分布式系统工具集,还需要面临Scala语言的挑战,探索一条SOA架构新路径。这是Peter Bourgon在2015年2月于 Google Campus London meetup上的讲话:Go kit: Go in the modern enterprise,这篇文章开篇将Scala损了一通是其亮点:

当我们谈到企业一词时,已经不再是老年缓慢象征的那些官僚企业,如IBM HP 甚至RedHat,几十年来,已经有很多其他公司成为技术领袖,比如Google Amazon Twitter Netflix Facebook Spotify甚至包括SoundCloud,这些现代企业已经为我们行业基本定调,共同的几个特点是:

1.面向技术Tech-oriented

2.聚焦消费者Consumer-focused

3.成功的创新增长

4.100–1000+大量工程师

5.面向服务架构SOA

面向服务的架构

大部分现代企业采用面向服务的架构,演进模式有以下共同特征:

1.开始使用Ruby-on-Rails (或类似之类语言框架)编写整体型 monolith铁板一块的应用。

2.将关键整块组件切分为服务,走向SOA

3.也许,进一步解构为微型服务microservice

SOA有很大优势,也有代价,任何一系列网络服务要比整体型monolith更复杂,由于分布式计算 以及管理的复杂性,通常开始需要依据惯例或最佳实践,并最终演变为库与框架,在现代企业中,事实上的标准也开始出现,它们经常是开源项目,Twitter的Finagle看上去最有标志性,Netflix也维护一套技术堆栈。

这些库包开始使用Scala编写,并受到JVM语言的限制,Scala有许多优点,表现力 宽容和无可置疑的快速,但是它不是万能的,不管以什么标准衡量,它巨复杂,有不可否认困难的工具链,而且经常不清楚--甚至是自相矛盾的语言设计(banq注:将OO与FP结合在一起会让人抓狂),这意味着它很难理解,也许没有人能够彻底完全理解它,不可避免产生的后果是反模式:cargo-culting, reinventing以及因为抽象泄漏导致误解问题产生的缝缝补补patching。

在这样的环境中,像Go语言就有出头机会,它有条理的设计考虑,开发者友好的工具链,原生库包架构,接近C的性能效率,令它在SOA中有难以置信的吸引力,特别是有别于当前艺术状态。Go还需要成熟的生态系统和广泛的成功应用案例,全面的分布式服务工具包,这些相信将来会填补。

GO需要什么

Go需要类似Finagle风格的工具集,一个Go kit工具集,让它成为现代面向服务型企业中一个可行的替代语言。

...

这些工具集包括:度量包;日志包;服务器包(健康心跳检查,系统请求跟踪,连接管理,后压和节流等);客户端包(请求跟踪,速率限制,断路,连接池);服务发现;transport 包(JSON支持等);

如果我们的分布式系统的可靠性遵循一套规则,那么我们可以使用简化的假设来平衡,并建立一个更容易理解的、更可靠的成熟模型。毕竟,简单是可靠性的前提。

[该贴被banq于2015-02-12 09:01修改过]

                   

3
banq
2015-02-12 11:41

Go通过Docker完成SOA分布式套件的可能性极大,而且隐秘包容。

freebox
2015-02-12 11:49

不管怎么说,语法上的习惯对我来说还是很重要的。我猜想如果go采用groovy/java的语法,再凭借性能上的优势,可以轻易地取得大量用户。