Monthly Archives: March 2019

Eclipse 配置XDebug图文详解

1.php.ini配置 eaccelerator.shm_only="0" zend_extension ="D:\xampp\php\ext\php_xdebug.dll" ;载入Xdebug [xdebug] ;开启远程调试 xdebug.remote_enable = 1 xdebug.profiler_enable = off xdebug.profiler_enable_trigger = off xdebug.profiler_output_name =cachegrind.out.%t.%p xdebug.profiler_output_dir ="D:\xampp\tmp" xdebug.show_local_vars=0   ;开启自动跟踪 xdebug.auto_trace = 1 ;开启异常跟踪 xdebug.show_exception_trace = 1 ;开启异常跟踪 xdebug.remote_autostart = 1 ;收集变量 xdebug.collect_vars = 1 ;收集参数 xdebug.collect_params = 1 ;trace输出路径 xdebug.trace_output_dir ="D:\xampp\tmp" ;以下三个分别是主机、端口、句柄 xdebug.remote_host="127.0.0.1" xdebug.remote_port=9000 xdebug.remote_handler="dbgp"         2.eclipse配置修改 2.1.     位置：windows->Preferences 2. 2      配置Executables(配置完成后，若设置断点能正常让XDebug运行，则无需继续设置其他选项)       2.3.配置 PHP Debug 将Server Settings下的Debugger设为XDebug     2.4.配置Debuggers   2.5配置workbench Options   from:https://blog.csdn.net/user1218/article/details/51135753

开发常用

开发常用的知识点和网址。

eclipse环境下报错：log cannot be resolved

在eclipse环境下使用@Slf4j注解时，出现了log cannot be resolved这个异常。经过排查发现是缺少lombok插件的问题。解决方式当然是在eclipse中安装lombok插件啦。 前往官网下载：https://projectlombok.org/download

滚动加载图片（懒加载）实现原理

本文主要通过以下几方面来说明懒加载技术的原理，个人前端小菜，有错误请多多指出 一、什么是图片滚动加载？ 通俗的讲就是：当访问一个页面的时候，先把img元素或是其他元素的背景图片路径替换成一张大小为1*1px图片的路径（这样就只需请求一次），只有当图片出现在浏览器的可视区域内时，才设置图片正真的路径，让图片显示出来。这就是图片懒加载。 二、为什要使用这个技术？ 比如一个页面中有很多图片，如淘宝、京东首页等等，如果一上来就发送这么多请求，页面加载就会很漫长，如果js文件都放在了文档的底部，恰巧页面的头部又依赖这个js文件，那就不好办了。更为要命的是：一上来就发送百八十个请求，服务器可能就吃不消了（又不是只有一两个人在访问这个页面）。 因此优点就很明显了：不仅可以减轻服务器的压力，而且可以让加载好的页面更快地呈现在用户面前（用户体验好）。 三、怎么实现？ 关键点如下： 1、页面中的img元素，如果没有src属性，浏览器就不会发出请求去下载图片（也就没有请求咯，也就提高性能咯），一旦通过javascript设置了图片路径，浏览器才会送请求。有点按需分配的意思，你不想看，就不给你看，你想看了就给你看~ 2、如何获取正真的路径，这个简单，现在正真的路径存在元素的“data-url”（这个名字起个自己认识好记的就行）属性里，要用的时候就取出来，再设置； 3、开始比较之前，先了解一些基本的知识，比如说如何获取某个元素的尺寸大小、滚动条滚动距离及偏移位置距离；   1）屏幕可视窗口大小：对应于图中1、2位置处 原生方法：window.innerHeight 标准浏览器及IE9+ || document.documentElement.clientHeight 标准浏览器及低版本IE标准模式 || document.body.clientHeight 低版本混杂模式 jQuery方法： $(window).height() 2）浏览器窗口顶部与文档顶部之间的距离，也就是滚动条滚动的距离：也就是图中3、4处对应的位置； 原生方法：window.pagYoffset——IE9+及标准浏览器 || document.documentElement.scrollTop 兼容ie低版本的标准模式 || document.body.scrollTop 兼容混杂模式； jQuery方法：$(document).scrollTop(); 3）获取元素的尺寸：对应于图中5、6位置处；左边jquery方法，右边原生方法 $(o).width() = o.style.width; $(o).innerWidth() = o.style.width+o.style.padding; $(o).outerWidth() = o.offsetWidth = o.style.width+o.style.padding+o.style.border; $(o).outerWidth(true) = o.style.width+o.style.padding+o.style.border+o.style.margin; 注意：要使用原生的style.xxx方法获取属性，这个元素必须已经有内嵌的样式，如<div style="…."></div>； 如果原先是通过外部或内部样式表定义css样式，必须使用o.currentStyle[xxx] || document.defaultView.getComputedStyle(0)[xxx]来获取样式值 4）获取元素的位置信息：对应与图中7、8位置处 1）返回元素相对于文档document顶部、左边的距离； jQuery：$(o).offset().top元素距离文档顶的距离，$(o).offset().left元素距离文档左边缘的距离 原生：getoffsetTop()，高程上有具体说明，这边就忽略了； 顺便提一下返回元素相对于第一个以定位的父元素的偏移距离，注意与上面偏移距的区别； jQuery：position()返回一个对象，$(o).position().left = style.left，$(o).position().top = style.top； 4、知道如何获取元素尺寸、偏移距离后，接下来一个问题就是：如何判断某个元素进入或者即将进入可视窗口区域？下面也通过一张图来说明问题。 1）外面最大的框为实际页面的大小，中间浅蓝色的框代表父元素的大小，对象1~8代表元素位于页面上的实际位置；以水平方向来做如下说明！ 2）对象8左边界相对于页面左边界的偏移距离（offsetLeft）大于父元素右边界相对于页面左边界的距离，此时可判读元素位于父元素之外； 3）对象7左边界跨过了父元素右边界，此时：对象7左边界相对于页面左边界的偏移距离（offsetLeft）小于 父元素右边界相对于 页面左边界的距离，因此对象7就进入了父元素可视区； 4）在对象6的位置处，对象5的右边界与页面左边界的距离 大于 父元素左边界与页面左边界的距离； 5）在对象5位置处时，对象5的右边界与页面左边界的距离 小于 父元素左边界与页面左边界的距离；此时，可判断元素处于父元素可视区外； 6）因此水平方向必须买足两个条件，才能说明元素位于父元素的可视区内；同理垂直方向也必须满足两个条件；具体见下文的源码； 四、扩展为jquery插件 使用方法：$("selector").scrollLoad({ 参数在代码中有说明 })

五、参考： 1、jQuery.lazyload详解 2、张大大：http://www.zhangxinxu.com/wordpress/?p=1259 3、Jquery图片延迟加载插件jquery.lazyload. http://www.daxueit.com/article/3944.html 4、jQuery.lazyload实现延时加载详解步骤 http://www.daxueit.com/article/21.html 5、jquery lazyload延迟加载技术的实现原理分析 http://www.daxueit.com/article/3777.html 6、Lazyload 延迟加载效果 7、图片延迟加载（lazyload）的实现原理

VS2017 启动调试出现 无法启动程序“http://localhost:15613” 操作在当前状态中是非法的

调试的时候报这样的错误 解决办法： 工具--选项--调试--常规--启用asp.net的JavaScript调试（chrome和ie）去掉勾选   from:http://www.mamicode.com/info-detail-2349622.html

win7下 VirtualBox虚拟机开机后台自启动

win7下安装个linux虚拟机，学习下非常好。 但是每次使用linux的时候，都是打开virtualBox-->启动安装的linux系统-->再用远程桌面（SSH等）连接 每次手动打开比较麻烦，而且linux虚拟机也有窗口，比较冗杂。如果能开机自启，并且后台运行linux虚拟机（没有可见窗口），那就开心了。   找到VirtualBox的安装目录  我的virtualbox安装在 D:\virualBox，进入这个目录，你会看到有个VBoxManage.exe文件，没有错，我们就是用它来启动虚拟机的。 怎么启动呢？命令行如下 VBoxManage startvm <uuid>|<name> [--type gui|sdl|headless] 比如我新建的虚拟机叫study，那么 D:\virualBox\VBoxManage startvm study --type headless 　　　　　　　　　　　　　　　--type headless:表示后台执行，没有窗口哦 来，我们打开cmd，试下这个命令 提示已经启动了study虚拟机了。     开机自启动 现在看不到窗口了，但是还是需要手动输入命令行启动。如果能开机自启动就好了 1、首选我们要做一个bat脚本：virtualboxtStart.bat 2、里面写入上面的命令：D:\virualBox\VBoxManage startvm study --type headless 3、把virtualboxtStart.bat放到C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup，这个目录下的脚本是开机的时候自动运行的哦   好了，小工告成。重启电脑，你就会发现，win7偷偷帮我们启动了study这个虚拟机了。 可以用SSH连接，操作了。   注：也可以在cmd中使用命令行对虚拟机进行状态管理： VBoxManage controlvm   <uuid>|<name>   pause|resume|reset|poweroff|savestate| 比如我想关闭： D:\virualBox\VBoxManage controlvm  study  poweroff   from:https://www.cnblogs.com/zmfly/p/5895718.html

微服务：从设计到部署——七、重构单体应用为微服务

本书主要介绍如何使用微服务构建应用程序，这是本书的第七章，也是最后一章。第一章介绍了微服务架构模式，讨论了使用微服务的优点与缺点。随后的章节讨论了微服务架构的方方面面：使用 API ​​网关、进程间通信、服务发现、事件驱动数据管理和部署微服务。在本章中，我们将介绍单体应用迁移到微服务的策略。 我希望这本电子书能够让您对微服务架构、其优点和缺点以及何时使用它有很好的了解。微服务架构也许很适合您的组织。 您正工作于大型复杂的单体应用程序上，这是相当不错的机会。然而，您开发和部署应用程序的日常经历是缓慢而痛苦的。微服务似乎是一个遥不可及的天堂。幸运的是，有一些策略可以用来逃离单体应用的地狱。在本文中，我将描述如何将单体应用程序逐渐重构为一组微服务。 7.1、微服务重构概述 单体应用程序转换为微服务的过程是应用程序现代化的一种形式。这是几十年来开发人员一直在做的事情。因此，在将应用程序重构为微服务时，有一些想法是可以重用的。 一个不要使用的策略是“大爆炸”重写。就是您将所有的开发工作都集中在从头开始构建新的基于微服务的应用程序。虽然这听起来很吸引人，但非常危险，有可能会失败。据 Martin Fowler 讲到：“大爆炸重写的唯一保证就是大爆炸！”（"the only thing a Big Bang rewrite guarantees is a Big Bang!"）。 您应该逐步重构单体应用程序，而不是通过大爆炸重写。您可以逐渐添加新功能，并以微服务的形式创建现有功能的扩展 — 以互补的形式修改单体应用，并且一同运行微服务和修改后的单体应用。随着时间推移，单体应用程序实现的功能量会缩小，直到它完全消失或变成另一个微服务。这种策略类似于在 70公里/小时的高速公路上驾驶一辆汽车，很具挑战性，但比尝试大爆炸改写的风险要小得多。 Martin Fowler 将这种应用现代化策略称为杀手应用（Strangler Application）。这个名字来自发现于热带雨林中的葡萄树（也称为绞杀榕）。一棵葡萄树生长在一棵树上，以获取森林冠层之上的阳光。有时，树死了，留下一个树形的腾。应用现代化也遵循相同的模式。我们将构建一个新的应用程序，包括了围绕遗留应用的微服务（它将会慢慢缩小或者最终消亡）。 让我们来看看能做到这点的不同策略。 7.2、策略一：停止挖掘 洞穴定律说到，每当您身处在一个洞穴中，您应该停止挖掘。当您的单体应用变得难以管理时，这是一个很好的建议。换句话说，您应该停止扩张，避免使单体变得更大。这意味着当您要实现新功能时，您不应该向单体添加更多的代码。相反，这一策略的主要思想是将新代码放在独立的微服务中。 应用此方法后，系统架构如图 7-1 所示。 除了新服务和遗留的单体应用，还有另外两个组件。第一个是请求路由，它处理传入的（HTTP）请求，类似于第二章中描述的 API 网关。路由向新服务发送与新功能相对应的请求。它将遗留的请求路由到单体应用。 另一个组件是粘合代码，它将微服务与单体应用集成。一个服务很少孤立存在，通常需要访问单体应用的数据。位于单体应用、微服务或两者中的粘合代码负责数据集成。该微服务使用粘合代码来读取和写入单体应用数据。 服务可以使用三种策略来访问单体应用的数据： 调用由单体应用提供的远程 API 直接访问单体应用的数据库 维护自己的数据副本，与单体应用的数据库同步 粘合代码有时被称为防护层（anti-corruption layer）。这是因为粘合代码阻止了服务被遗留的单体应用领域模型的概念所污染，这些服务拥有属于自己的新的领域模型。粘合代码在两种不同的模型之间转换。防护层一词首先出现于埃里克·埃文斯（Eric Evans）所著的必读图书《领域驱动设计》（Domain Driven Design）中，并在白皮书中进行了改进。开发一个防护层并不是一件简单的事情。但是，如果您想要从单体应用地狱中走出来，这是必不可少的步骤。 使用轻量级服务来实现新功能有几个好处。它防止单体变得更加难以管理。该服务可以独立于单体应用开发、部署和扩展。可让您创建的每个新服务体验到微服务架构的优势。 然而，这种方法没有解决单体应用的问题。要解决这些问题，您需要分解单体应用。让我们来看看这样做的策略。 7.3、策略二：前后端分离 缩小单体应用的一个策略是从业务逻辑层和数据访问层拆分出表现层。一个典型的企业应用由至少三种不同类型的组件组成： 表现层（Presentation Layer，PL） 处理 HTTP 请求并实现（REST）API 或基于 HTML 的 Web UI 组件。在具有复杂用户界面的应用中，表现层通常存在大量代码。 业务逻辑层（Business Logic Layer，BLL） 作为应用程序核心，实现业务规则的组件。 数据访问层（Data Access Layer，DAL） 访问基础架构组件的组件，如数据库和消息代理。 表现逻辑部分与业务和数据访问逻辑部分之间通常有一个清晰的界限。业务层具有由一个或多个门面组成的粗粒度 API，其封装了业务逻辑组件。这个 API 是一个天然的边界，您可以沿着该边界将单体应用拆分成两个较小的应用程序。一个应用程序包含表现层。另一个应用程序包含业务和数据访问逻辑。分割后，表现逻辑应用程序对业务逻辑应用程序进行远程调用。 重构之前和之后的架构如图 7-2 所示。 以这种方式拆分单体应用有两个主要优点。它使您能够独立于彼此开发、部署和扩展这两个应用。特别是它允许表现层开发人员在用户界面上快速迭代，并且可以轻松执行 A/B 测试。这种方法的另一个优点是它暴露了可以被微服务调用的远程 API。 然而，这一策略只是一个局部解决方案。两个应用程序中的一个或两个很可能在将来膨胀成一个无法管理的单体应用。您需要使用第三种策略来继续消减单体应用。 7.4、策略三：提取服务 第三个重构策略是将庞大的现有模块转变为独立的微服务。每次提取一个模块并将其转换成微服务时，单体就会缩小。一旦您转换了足够的模块，单体应用将不再是一个问题。或者它完全消失，或者变得小到可以被当做一个服务看待。 7.4.1、优先将哪些模块转换为微服务 […]

微服务：从设计到部署——六、选择部署策略

本书主要介绍关于如何使用微服务构建应用程序，这是本书的第六章。第一章介绍了微服务架构模式，讨论了使用微服务的优点与缺点。之后的章节讨论了微服务架构的方方面面：使用 API 网关、进程间通信、服务发现和事件驱动数据管理。在本章中，我们将介绍部署微服务的策略。 6.1、动机 部署单体应用程序意味着运行一个或多个相同副本的单个较大的应用程序。您通常会配置 N 个服务器（物理或虚拟），每台服务器上会运行 M 个应用程序实例。单体应用程序的部署并不总是非常简单，但它比部署微服务应用程序要简单得多。 微服务应用程序由数十甚至上百个服务组成。服务以不同的语言和框架编写。每个都是一个迷你的应用程序，具有自己特定的部署、资源、扩展和监视要求。例如，您需要根据该服务的需求运行每个服务的一定数量的实例。此外，必须为每个服务实例提供相应的 CPU、内存和 I/O 资源。更具挑战性的是尽管如此复杂，部署服务也必须快速、可靠和具有成本效益。 有几种不同的微服务部署模式。我们首先看看单主机多服务实例模式。 6.2、单主机多服务实例模式 部署微服务的一种方式是使用单主机多服务实例（Multiple Service Instances per Host）模式。当使用此模式时，您可以提供一个或多个物理主机或虚拟主机，并在每个上运行多个服务实例。从多方面来讲，这是应用程序部署的传统方式。每个服务实例在一个或多个主机的标准端口上运行。主机通常被当作宠物对待。 图 6-1 展示了该模式的结构： 这种模式有几个变体。一个变体是每个服务实例都是一个进程或进程组。例如，您可以在 Apache Tomcat 服务器上将 Java 服务实例部署为 Web 应用程序。一个 Node.js 服务实例可能包含一个父进程和一个或多个子进程。 此模式的另一个变体是在同一进程或进程组中运行多个服务实例。例如，您可以在同一个 Apache Tomcat 服务器上部署多个 Java Web 应用程序，或在同一 OSGI 容器中运行多个 OSGI 软件包。 单主机多服务实例模式有优点也有缺点。主要优点是其资源使用率相对较高。多个服务实例共享服务器及其操作系统。如果进程或进程组运行了多个服务实例（例如，共享相同的 Apache Tomcat 服务器和 JVM 的多个 Web 应用程序），则效率更高。 这种模式的另一个优点是部署服务实例相对较快。您只需将服务复制到主机并启动它。如果服务是使用 Java 编写的，则可以复制 JAR 或 WAR 文件。对于其他语言，例如 Node.js 或 Ruby，您可以直接复制源代码。在任一情况下，通过网络复制的字节数都是相对较小的。 另外，由于缺乏开销，通常启动一个服务是非常快的。如果该服务是自己的进程，你只需要启动它即可。如果服务是在同一容器进程或进程组中运行的几个实例之一，则可以将其动态部署到容器中或者重新启动容器。 尽管这很有吸引力，但单主机多服务实例模式有一些明显的缺点。一个主要的缺点是服务实例很少或者没有隔离，除非每个服务实例是一个单独的进程。虽然您可以准确地监视每个服务实例的资源利用率，但是您不能限制每个实例使用的资源。一个行为不当的服务实例可能会占用掉主机的所有内存或 CPU。 如果多个服务实例在同一进程中运行，那么将毫无隔离可言。例如，所有实例可能共享相同的 JVM 堆。行为不当的服务实例可能会轻易地破坏在同一进程中运行的其他服务。此外，您无法监控每个服务实例使用的资源。 这种方式的另一个重要问题是部署服务的运维团队必须了解部署的具体细节。服务可以用多种语言和框架编写，因此开发团队必须与运维交代许多细节。这种复杂性无疑加大了部署过程中的错误风险。 正如您所见，尽管这种方式简单，但单主机多服务实例模式确实存在一些明显的缺点。现在让我们来看看可以绕过这些问题部署微服务的其他方式。 6.3、每个主机一个服务实例模式 部署微服务的另一种方式是使用每个主机一个服务实例（Service Instance per Host）模式。当使用此模式时，您可以在主机上单独运行每个服务实例。这种模式有两种不同形式：每个虚拟机一个服务实例模式和每个容器一个服务实例模式。 6.3.1、每个虚拟机一个服务实例模式 当您使用每个虚拟机一个服务实例模式时，将每个服务打包成一个虚拟机（VM）镜像（如 Amazon EC2 AMI）。每个服务实例都是一个使用该 VM 镜像启动的 VM（例如，一个 EC2 实例）。 图 6-2 展示了该模式的结构： 这是 Netflix 部署其视频流服务的主要方式。Netflix 使用 Aminator 将每个服务打包为 EC2 […]

微服务：从设计到部署——五、事件驱动数据管理

本书主要介绍如何使用微服务构建应用程序，这是本书的第五章。第一章介绍了微服务架构模式，讨论了使用微服务的优点与缺点。第二和第三章描述了微服务架构内通信方式的对比。第四章探讨了与服务发现相关的内容。在本章中，我们稍微做了点调整，研究微服务架构中出现的分布式数据管理问题。 5.1、微服务和分布式数据管理问题 单体应用程序通常具有一个单一的关系型数据库。使用关系型数据库的一个主要优点是您的应用程序可以使用 ACID 事务，这些事务提供了以下重要保障： 原子性（Atomicity） — 所作出的更改是原子操作，不可分割 一致性（Consistency） — 数据库的状态始终保持一致 隔离性（Isolation） — 即使事务并发执行，但他们看起来更像是串行执行 永久性（Durable） — 一旦事务提交，它将不可撤销 因此，您的应用程序可以很容易地开始事务、更改（插入、更新和删除）多行记录，并提交事务。 使用关系型数据库的另一大好处是它提供了 SQL，这是一种丰富、声明式和标准化的查询语言。您可以轻松地编写一个查询，组合来自多个表的数据，之后，RDBMS 查询计划程序将确定执行查询的最佳方式。您不必担心如何访问数据库等底层细节。因为您所有的应用程序数据都存放在同个数据库中，因此很容易查询。 很不幸的是，当我们转向微服务架构时，数据访问将变得非常复杂。因为每个微服务所拥有的数据对当前微服务来说是私有的，只能通过其提供的 API 进行访问。封装数据可确保微服务松耦合、独立演进。如果多个服务访问相同的数据，模式（schema）更新需要对所有服务进行耗时、协调的更新。 更糟糕的是，不同的微服务经常使用不同类型的数据库。现代应用程序存储和处理着各种数据，而关系型数据库并不总是最佳选择。在某些场景，特定的 NoSQL 数据库可能具有更方便的数据模型，提供了更好的性能和可扩展性。例如，存储和查询文本的服务使用文本搜索引擎（如 Elasticsearch）是合理的。类似地，存储社交图数据的服务应该可以使用图数据库，例如 Neo4j。因此，基于微服务的应用程序通常混合使用 SQL 和 NoSQL 数据库，即所谓的混合持久化（polyglot persistence）方式。 分区的数据存储混合持久化架构具有许多优点，包括了松耦合的服务以及更好的性能与可扩展性。然而，它也引入了一些分布式数据管理方面的挑战。 第一个挑战是如何实现业务的事务在多个服务之间保持一致性。要了解此问题，让我们先来看一个在线 B2B 商店的示例。Customer Service （顾客服务）维护客户相关的信息，包括信用额度。Order Service （订单）负责管理订单，并且必须验证新订单，不得超过客户的信用额度。在此应用程序的单体版本中，Order Service 可以简单地使用 ACID 事务来检查可用信用额度并创建订单。 相比之下，在微服务架构中，ORDER （订单）和 CUSTOMER （顾客）表对其各自的服务都是私有的，如图 5-1 所示： Order Service 无法直接访问 CUSTOMER 表。它只能使用客户服务提供的 API。订单服务可能使用了分布式事务，也称为两阶段提交（2PC）。然而，2PC 在现代应用中通常是不可行的。CAP 定理要求您在可用性与 ACID 式一致性之间做出选择，可用性通常是更好的选择。此外，许多现代技术，如大多数 NoSQL 数据库，都不支持 2PC。维护服务和数据库之间的数据一致性至关重要，因此我们需要另一套解决方案。 第二个挑战是如何实现从多个服务中检索数据。例如，我们假设应用程序需要显示一个顾客和他最近的订单。如果 Order Service 提供了用于检索客户订单的 API，那么您可以使用应用程序端连接以检索数据。应用程序从 Customer Service 中检索客户，并从 Order Service 中检索客户的订单。但是，假设 Order Service 仅支持通过主键查找订单（也许它使用了仅支持基于主键检索的 NoSQL 数据库）。在这种情况下，没有有效的方法来检索所需的数据。 5.2、事件驱动架构 许多应用使用了事件驱动架构作为解决方案。在此架构中，微服务在发生某些重要事件时发布一个事件，例如更新业务实体时。其他微服务订阅了这些事件，当微服务接收到一个事件时，它可以更新自己的业务实体，这可能导致更多的事件被发布。 您可以使用事件实现跨多服务的业务的事务。一个事务由一系列的步骤组成。每个步骤包括了微服务更新业务实体和发布一个事件来触发下一步骤。下图依次展示了如何在创建订单时使用事件驱动方法来检查可用信用额度。 微服务通过 Message Broker （消息代理）进行交换事件： Order Service （订单服务）创建一个状态为 NEW 的订单，并发布一个 […]

微服务：从设计到部署——四、服务发现

本书主要介绍如何使用微服务来构建应用程序，现在是第四章。第一章已经介绍了微服务架构模式，并讨论了使用微服务的优点与缺点。第二章和第三章介绍了微服务间的通信，并对不同的通信机制作出对比。在本章中，我们将探讨服务发现（service discovery）相关的内容。 4.1、为何使用服务发现 我们假设您正在编写某些代码，这些代码调用了有 REST API 或 Thrift API 的服务。为了发送一个请求，您的代码需要知道服务实例的网络位置（IP 地址与端口）。在运行于物理硬件上的传统应用中，服务实例的网络位置是相对静态的。例如，您的代码可以从偶尔更新的配置文件中读取网络位置。 然而，在现代基于云的微服务应用中，这是一个更难解决的问题，如图 4-1 所示。 服务实例具有动态分配的网络位置。此外，由于自动扩缩、故障与升级，整组服务实例会动态变更。因此，您的客户端代码需要使用更精确的服务发现机制。 有两种主要的服务发现模式：客户端发现（client-side discovery）与服务端发现（server-side discovery）。让我们先来看看客户端发现。 4.2、客户端发现模式 当使用客户端发现模式时，客户端负责确定可用服务实例的网络位置和请求负载均衡。客户端查询服务注册中心（service registry），它是可用服务实例的数据库。之后，客户端利用负载均衡算法选择一个可用的服务实例并发出请求。 图 4-2 展示了该模式的结构 服务实例的网络位置在服务注册中心启动时被注册。当实例终止时，它将从服务注册中心中移除。通常使用心跳机制周期性地刷新服务实例的注册信息。 Netflix OSS 提供了一个很好的客户端发现模式示例。Netflix Eureka 是一个服务注册中心，它提供了一组用于管理服务实例注册和查询可用实例的 REST API。Netflix Ribbon 是一个 IPC 客户端，可与 Eureka 一起使用，用于在可用服务实例之间使请求负载均衡。本章稍后将讨论 Eureka。 客户端发现模式存在各种优点与缺点。该模式相对比较简单，除了服务注册中心，没有其他移动部件。此外，由于客户端能发现可用的服务实例，因此可以实现智能的、特定于应用程序的负载均衡决策，比如使用一致性哈希。该模式的一个重要缺点是它将客户端与服务注册中心耦合在一起。您必须为您使用的每种编程语言和框架实现客户端服务发现逻辑。 现在我们已经了解了客户端发现，接下来让我们看看服务端发现。 4.3、服务端发现模式 服务发现的另一种方式是服务端发现模式。图 4-3 展示了该模式的结构： 客户端通过负载均衡器向服务发出请求。负载均衡器查询服务注册中心并将每个请求路由到可用的服务实例。与客户端发现一样，服务实例由服务注册中心注册与销毁。 AWS Elastic Load Balancer（ELB）是一个服务端发现路由示例。ELB 通常用于负载均衡来自互联网的外部流量。然而，您还可以使用 ELB 来负载均衡虚拟私有云（VPC）内部的流量。客户端通过 ELB 使用其 DNS 名称来发送请求（HTTP 或 TCP）。ELB 负载均衡一组已注册的 Elastic Compute Cloud（EC2）实例或 EC2 Container Service（ECS）容器之间的流量。这里没有单独可见的服务注册中心。相反，EC2 实例与 ECS 容器由 ELB 本身注册。 HTTP 服务器和负载均衡器（如 NGINX Plus 和 NGINX）也可以作为服务端发现负载均衡器。例如，此博文描述了使用 Consul Template 动态重新配置 NGINX 反向代理。Consul Template 是一个工具，可以从存储在 Consul 服务注册中心中的配置数据中定期重新生成任意配置文件。每当文件被更改时，它都会运行任意的 shell 命令。在列举的博文描述的示例中，Consul […]