微服务实现工具概述(微服务)

作者:xinwang_m@163.com
发布时间: 2020-07-21 03:50:25 (4年前)
关键词: 微服务
摘要:

                              
                                     核心微服务是一个完整应用开发和交付架构的一部分，需要为内部服务之间通讯选择合适的工具，包括流量监控工具、失败探测工具等等，下面一些软件和工具可以帮助你切换到微服务架构。

<h2><a href="#微服务实现工具概述" name="微服务实现工具概述">微服务实现工具概述</a></h2><p>　　核心微服务是一个完整应用开发和交付架构的一部分，需要为内部服务之间通讯选择合适的工具，包括流量监控工具、失败探测工具等等，下面一些软件和工具可以帮助你切换到微服务架构。</p><h2><a href="#开源软件" name="开源软件">开源软件</a></h2><p>　　如果你正在构建基于应用的微服务，你会发现，大部分的最好的代码都是开源的。它们来自于拥有一流的技术人才的公司，像谷歌， LinkedIn ， Netflix，和Twitter 。因为这些公司的特点性质，这些项目通常都有建立可扩展性大型系统的初衷。所有这一切都使得软件开发领域非常不同于十年或十五年前，那时候你需要一个庞大的团队和大量金钱来购买软件，更别说昂贵的硬件。现在，再也没有漫长的采购周期等待，你自己可以改变和扩展自己的软件。</p><h2><a href="#内外部通讯协议" name="内外部通讯协议">内外部通讯协议</a></h2><p>　　建立带有对外的API微服务时，通常你还需要考虑API是如何被调用的，通常采取XML/JSON协议，但是因为微服务本身粒度比较细，微服务之间的通讯如同方法之间调用一样频繁，如何让不同机器之间的微服务之间通讯快速得像在本地内存对象之间方法一样调用快速是很重要的。这个情况下，JSON/XML已经不够了，系统大部分CPU时间不是在运行业务逻辑，而是耗费在将你的语言代码与JSON/XML的数据之间转换上，这时候，采取二进制byte编码应该考虑了，目前方案包括： Protocol Buffers 来自 Google, 以及 Thrift 和 Avro 来自Apache. 一个新的协议是 Simple Binary Encoding 是来自Real Logic Limited, 据报道比Protocol Buffer要快 20 倍.</p><p>　　使用二进制编码意味着调用API时必须使用辅助的库包，这个客户端调用的库包最好由你提供，因为如果其他人编写，他们可能无法像你一样深刻理解API。</p><h2><a href="#数据存储" name="数据存储">数据存储</a></h2><p>　　如果当前有monolithic（铁板一块 整体 巨石）的数据存储在你的应用后面，你需要切分它们以便转换到微服务， Refactoring Databases: Evolutionary Database Design 一文可以获得建议，你能够使用SchemaSpy 分析你的Schema，你的目标是为每个微服务确定其需要的物化视图，将它们从绑定在一起的数据库的表结构转为微服务风格的数据存储，这并不一定像你预料得那么困难，因为monolithic数据库原来也是不同的数据表集合，这些数据表以前也是被一个个服务单独访问，因此很容易分裂隔离它们。</p><p>　　也可以随着时间推移逐步切割它们， Netflix OSS 一个项目 staash它是一个Java应用，可以提供RESTful API前端来与Cassandra和mySQL数据库同时通讯，这样你可以设置它作为一个标准的数据访问层的标准原型库，你能增加新的数据库到后端，增加新的HTTP到前端，这些都只要使用staash作为一个单独包库即可，因为在其中已经包含了协调mySQL和Cassandra所必要的各种文件。</p><p>　　如果你关心分布式存储的一致性问题，可参考 Kyle Kingsbury的 Jepsen tests, 它已经成为测试分布式系统如何应对网络分区的标准测试方法，大多数数据库都这个测试中都失败了，很多有趣的bug被暴露出来，这个测试能帮助你识别和消除常见的实战问题。</p><h2><a href="#监控" name="监控">监控</a></h2><p>　　监测微服务部署是困难的，因为服务集的变化得是如此之快。有不断添加新服务，新的度量数据收集，新版本被部署，增加扩展和缩小服务实例，等等此类情况。在这样的环境中，没有足够的基准数据让自动学习的有阈值判断的分析工具知道正常流量是什么样子，这类工具往往就会产生大量的误报，尤其是当你开始启动它们从来没有见过的新的微服务时。面临的挑战是建立一个适当的对环境状态变化的反应，这个环境的变化是如此频繁，一切看起来不同于寻常的系统。</p><p>　　微服务架构还涉及到复杂的远程调用模式作为服务进行通信。这使得在端至端跟踪流动请求变得更加困难，但是跟踪数据对于诊断问题是非常重要的，你能够跟踪流程A是如何被B调用，B又是如何被C调用，一种途径是使用一个全局标识(GUID)和事务ID放入HTTP头部中进行跟踪测量。</p><h2><a href="#持续交付和devops" name="持续交付和devops">持续交付和DevOps</a></h2><p>　　在一个微服务架构，你会很频繁部署的小软件。最有可能打破系统的变化是涉及到某一个被很多客户端使用的功能，单个功能会导致小的性能下降可能不会被注意到，但是所有客户端一起访问就可能突然使系统停机。为了应对这样的情况下，你必须非常迅速同时检测到问题，并回滚到以前的配置。为快速检测的问题，健康检查可以运行5到10秒，而不是是常见的1至5分钟。,## 微服务实现工具概述<br/>　　核心微服务是一个完整应用开发和交付架构的一部分，需要为内部服务之间通讯选择合适的工具，包括流量监控工具、失败探测工具等等，下面一些软件和工具可以帮助你切换到微服务架构。</p><h2><a href="#开源软件" name="开源软件">开源软件</a></h2><p>　　如果你正在构建基于应用的微服务，你会发现，大部分的最好的代码都是开源的。它们来自于拥有一流的技术人才的公司，像谷歌， LinkedIn ， Netflix，和Twitter 。因为这些公司的特点性质，这些项目通常都有建立可扩展性大型系统的初衷。所有这一切都使得软件开发领域非常不同于十年或十五年前，那时候你需要一个庞大的团队和大量金钱来购买软件，更别说昂贵的硬件。现在，再也没有漫长的采购周期等待，你自己可以改变和扩展自己的软件。</p><h2><a href="#内外部通讯协议" name="内外部通讯协议">内外部通讯协议</a></h2><p>　　建立带有对外的API微服务时，通常你还需要考虑API是如何被调用的，通常采取XML/JSON协议，但是因为微服务本身粒度比较细，微服务之间的通讯如同方法之间调用一样频繁，如何让不同机器之间的微服务之间通讯快速得像在本地内存对象之间方法一样调用快速是很重要的。这个情况下，JSON/XML已经不够了，系统大部分CPU时间不是在运行业务逻辑，而是耗费在将你的语言代码与JSON/XML的数据之间转换上，这时候，采取二进制byte编码应该考虑了，目前方案包括： Protocol Buffers 来自 Google, 以及 Thrift 和 Avro 来自Apache. 一个新的协议是 Simple Binary Encoding 是来自Real Logic Limited, 据报道比Protocol Buffer要快 20 倍.</p><p>　　使用二进制编码意味着调用API时必须使用辅助的库包，这个客户端调用的库包最好由你提供，因为如果其他人编写，他们可能无法像你一样深刻理解API。</p><h2><a href="#数据存储" name="数据存储">数据存储</a></h2><p>　　如果当前有monolithic（铁板一块 整体 巨石）的数据存储在你的应用后面，你需要切分它们以便转换到微服务， Refactoring Databases: Evolutionary Database Design 一文可以获得建议，你能够使用SchemaSpy 分析你的Schema，你的目标是为每个微服务确定其需要的物化视图，将它们从绑定在一起的数据库的表结构转为微服务风格的数据存储，这并不一定像你预料得那么困难，因为monolithic数据库原来也是不同的数据表集合，这些数据表以前也是被一个个服务单独访问，因此很容易分裂隔离它们。</p><p>　　也可以随着时间推移逐步切割它们， Netflix OSS 一个项目 staash它是一个Java应用，可以提供RESTful API前端来与Cassandra和mySQL数据库同时通讯，这样你可以设置它作为一个标准的数据访问层的标准原型库，你能增加新的数据库到后端，增加新的HTTP到前端，这些都只要使用staash作为一个单独包库即可，因为在其中已经包含了协调mySQL和Cassandra所必要的各种文件。</p><p>　　如果你关心分布式存储的一致性问题，可参考 Kyle Kingsbury的 Jepsen tests, 它已经成为测试分布式系统如何应对网络分区的标准测试方法，大多数数据库都这个测试中都失败了，很多有趣的bug被暴露出来，这个测试能帮助你识别和消除常见的实战问题。</p><h2><a href="#监控" name="监控">监控</a></h2><p>　　监测微服务部署是困难的，因为服务集的变化得是如此之快。有不断添加新服务，新的度量数据收集，新版本被部署，增加扩展和缩小服务实例，等等此类情况。在这样的环境中，没有足够的基准数据让自动学习的有阈值判断的分析工具知道正常流量是什么样子，这类工具往往就会产生大量的误报，尤其是当你开始启动它们从来没有见过的新的微服务时。面临的挑战是建立一个适当的对环境状态变化的反应，这个环境的变化是如此频繁，一切看起来不同于寻常的系统。</p><p>　　微服务架构还涉及到复杂的远程调用模式作为服务进行通信。这使得在端至端跟踪流动请求变得更加困难，但是跟踪数据对于诊断问题是非常重要的，你能够跟踪流程A是如何被B调用，B又是如何被C调用，一种途径是使用一个全局标识(GUID)和事务ID放入HTTP头部中进行跟踪测量。</p><h2><a href="#持续交付和devops" name="持续交付和devops">持续交付和DevOps</a></h2><p>　　在一个微服务架构，你会很频繁部署的小软件。最有可能打破系统的变化是涉及到某一个被很多客户端使用的功能，单个功能会导致小的性能下降可能不会被注意到，但是所有客户端一起访问就可能突然使系统停机。为了应对这样的情况下，你必须非常迅速同时检测到问题，并回滚到以前的配置。为快速检测的问题，健康检查可以运行5到10秒，而不是是常见的1至5分钟。</p>

0 条回复

动动手指，沙发就是你的了！

登录后才能参与评论