令人激动的微服务2.0技术栈

谈论微服务架构时,我们认识到:团队的组织方式与沟通结构对技术系统的设计有着很大影响。当我们实际开始实现这些架构时,会发现已经处于分布式系统中的较深位置。我们还发现,已经有许多技术和方法大大促进这一技术演变。因此,我们可能处在一个新的进化循环开始,这个新的进化就是以Lambda /函数作为服务风格。当然这里不想过多讲述。

当构建微服务时,我们真的深深进入了分析分布式系统 - 一个已经研究了40年以上的技术主题,复杂的自适应系统理论已经深入人心有很长的时间。从技术的角度来看,我们需要解决的事情如下:

部署
交付
API
版本控制
合同
缩放/自动缩放
服务发现
负载均衡
路由/自适应路由
健康检查
配置
断路器
bulk-heads
TTL / deadlining
延迟跟踪
服务因果跟踪
分布式日志
度量操作与收集

Netflix和其他互联网公司为解决其中一些问题做了一些事情(如开源软件或发布相关技术论文)。但是还是反复修改。真正令人兴奋的是,我们开始看到了下一波技术,以更优雅的方式解决了这些问题。

例如,Kubernetes是Google和Red Hat构建平台时使用的一组应用程序级原语,用于运行在容器上构建云本地应用程序。曾经有过迭代(无论是在Google还是在开源),但Kubernetes已经大大简化了像服务发现,扩展,部署等微服务环节。创建简单的东西其实并不容易。Kubernetes应该是github上最热的项目,现在大概1000多个提交者。那老厉害了!如果在5年前,你不会看到这么多的“微服务”框架解决服务发现,部署,故障转移,负载平衡等。

另一个例子是断路器。任何人都可以写一个断路器。Netflix甚至发布了他们的断路器(Hystrix库)作为OSS。应用程序可使用这个hystrix断路器库来实现断路功能,当希望保护自己免受下游异常尝试请求,包括控制发生故障的爆炸半径时,由它触发网络呼叫,。缺点(包括断路,服务发现,跟踪等)是开发者需要获得这些正确的库包,并将这些库包鼓捣在一起能够正常工作,却是很难。

Envoy项目
希望有一种不同的方式来解决这些。“更优雅”的做法,是把这些东西放在一个客户端代理,和你的应用被部署为一个“sidecar”。这是一个伟大的小项目,同时帮助我们的工具还有来自Lyft 的Envoy项目。Envoy是一个非常小的C ++客户端代理,用于处理诸如断路/批量堆栈/服务发现/度量收集/跟踪等操作。这意味着单个Envoy代理将与每个应用程序一起部署,不必考虑什么编程语言。应用程序基本上通过“localhost”与其他服务进行交谈,Envoy完全代理实际服务。它知道如何找到后端服务,做自适应路由,重试,跟踪,调节等。作为开发人员,可以让代码更干净,又能免费获得所有微服务的这些功能便利。


GRPC
最后,一般我们使用REST构建微服务。一个服务对外暴露一个REST端点,并使用REST实现服务之间的所有交互/集成。但它正在演变成一个更优雅的东西。REST达到一定规模以后,会存在一些问题包括跟踪服务之间的破碎变化,理解跨服务之间的类型安全,特别是相对于使用RPC风格的服务(至少在HTTP 1.x情况下)时会有相当大的开销。令人兴奋的是非阻塞通信框架(即RxJava,Vert.x),异步通信模式,甚至GRPC库包正在让事情变得更加优雅。

因此,令人兴奋的是,在开源社区新工具正在融合,将更多的复杂的东西推下一层(同时用最好的技术实现),从而进一步提高了构建业务应用程序的良好开发体验。

Excited about a '2.0' tech stack for microservices