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

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修改过]