文档结构  
翻译进度:已翻译     翻译赏金:0 元 (?)    ¥ 我要打赏
参与翻译: CY2 (6), llll (1)

image

来自未来的一封信,在未来可建设的事物和大规模生产系统都像创造一个软件一样简单。继续读下去,看看未来是什么样子的...

在2016年,人们写了很多次"微服务",有点像人们在1996年时写了那么多次“信息高速公路”一样。当“信息高速公路”这个词渐渐淡出人们的视野,人们返回到现实继续建造网络。当服务变成了简历可扩展软件系统的标准方法时,微服务的“微”的这一部分也渐渐淡出人们的想法。抛开我们用过的词汇(又被抛弃的词汇),这些词都标记着人们对科技的想法和使用的转变。使用基于服务的架构,意味着开发人员更注重服务和服务的便利以及发展速度的联系。

第 1 段(可获 2 积分)

image
信息高速公路的兴衰 (source)

从2016年开始,开发者效率很高是在于每次专注一个服务。什么是服务?基本上就是最小的软件有效片段,可以去简单定义和独立部署。比如通知服务,登陆服务,持久化键值存储服务。一个好的系统不仅仅做一件事,并且做的很给力。开发者可以很快行动,因为他们不需要担心虚拟机或者其他低端的架构:服务建立起抽象层(这也称为无服务的计算)。因为这些服务间的连接是显式的,开发者就自由想象应用作为整体,并把精力放在自己的功能和依赖的服务上。

第 2 段(可获 2 积分)

以前,很多公司觉得转向微服务不就是把一个二进制分割成10个更小的嘛。但他们发现还是有同样的老问题,就是重复了十遍罢了。慢慢他们也意识到搭建可靠应用不是说就是把单一整体分割成小片段,而是去理解各个片段的联系。开始问正确的问题:我的服务依赖什么服务?当依赖者不响应怎么办?还有什么服务会通过RPC(远程过程调用)到我的服务?期待多少RPC?回答这些问题需要新的工具和理念。

第 3 段(可获 2 积分)

工具

搭建基于服务的架构如果没有工具箱是不可能的,需要去理解独立性和服务间的内在特质。程序上使用的工具是,通过API的界限和服务间的关联。他们有效去定义不同服务的交换协议。这些工具也帮助文档化和测试服务,去生成很多在建立分布式应用的管道。

另一个重要工具可以帮助部署和协调服务:把高层服务对应到他们消费的底层资源(并恰当的规模化)的调度器,同时作服务发现和负载均衡去保障请求到达。

第 4 段(可获 2 积分)

最后,当部署一个新应用,第三方的工具帮助开发者理解基于服务的应用行为并帮助隔离问题。回到微服务的早期,开发者失去那种像单一应用的掌控能力。突然间他们不能对一个日志文件去搜索查找根源:现在需要从分布在100个节点的日志,交织1000个其他请求中去找答案。基于多进程的跟踪,聚合关键路径分析,和智能错误切入的先进技术才能让一个分布式系统变的可以理解。

这些工具到2016年也有了,但生态系统还不完善。有少量标准,但新工具需要大量投资,而现有的东西不能一起工作。

第 5 段(可获 2 积分)

新方法

当服务成为每天,每个开发者一种思考方式,部分是因为工具库。但当开发者在做软件时就思考服务第一和重要性,这场革命才刚开始。就像测试驱动的部署意味着开发者在一开始编写他们第一行代码时就得测试,服务驱动的部署意味者服务依赖性,性能监控,和RPC的上下文,这些作为最重要的考虑。

第 6 段(可获 2 积分)

总之,服务(微)是好东西(我们不需要去说“微服务”了,因为这不是靠服务的大小决定的:而是他们之间的连接和关系)。服务重现开始围绕在功能的软件部署,让开发者更快更独立去做他们关心的事情:这就是给用户提供价值!

回到现在,构建微服务生态系统仍有大量令人兴奋的工作需要去做,在 LightStep 我们很高兴成为这场变革的参与者,并跟进不断提高在生产系统中的知名度。如果想要讨论更多关于服务、跟踪等方面问题,请通过 hello@lightstep.com 或者 @lightstephq 联系我们,或者在下面的评论中发布。

第 7 段(可获 2 积分)

文章评论

CY2
本文部分章节转载自微信公众号:董老师在硅谷