Visual Studio International Feature Pack 2.0 汉字转拼音
下载地址 https://www.microsoft.com/zh-CN/download/details.aspx?id=18970 快速描述 Microsoft Visual Studio International Feature Pack 2.0 Visual Studio International Feature Pack 2.0 包含一组控件和类库，设计用来帮助.NET开发人员创建国际化程序。 概述 Visual Studio International Feature Pack 2.0 是对 1.0 版本( 1.0 版的产品名是 Microsoft Visual Studio International Pack 1.0 SR1) 的扩展,包含一组控件和类库，设计用来帮助.NET开发人员创建国际化程序。 1, Yomigana Framework 包含了类库和控件。 a, 类库：Yomigana 类库容许对串（string）类型加注 Yomigana，同时也支持对一般类型的注解功能，任何实现了IEnumerable接口的对象都可以被串类型和泛型的实例注解。为了简化复杂的注解字符串比较特设计了支持各种日文比较选项的比较类型。 1) 通用的一些类，用泛型实现对一个可枚举的类型注音。 2) 特殊目的的一些类，用以上泛型实现对一个字符串用某种类型中注音。 3) 特殊目的的一些StringAnnotation 类，用以上泛型实现对一个字符串用字符串注音，包括解析和格式化功能。 4) 一个比较器类，使用以上类实现比较字符串。 5) 一个实现了 IEnumerable 的数据结构，把一个字符串分成枚举的字符串段，并用 IEnumerator 输出。 b, 控件： 1) 增强的Ajax/WPF/WinForm 文本框（TextBox）控件 用来根据用户的输入捕获读音。 2) 一个增强的使用Ruby标签的ASP.NET Label控件。 2, Chinese Text Alignment Class Library and TextBox Controls 包含支持简体中文文本对齐的WinForm 和 WPF 的TextBox控件, 以及供帮助开发人员很容易地按中文文本对齐显示字符串的一个类库。 3, Chinese Auto Complete Class Library and […]
View DetailsEclipse 配置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
View Details
eclipse环境下报错：log cannot be resolved
在eclipse环境下使用@Slf4j注解时，出现了log cannot be resolved这个异常。经过排查发现是缺少lombok插件的问题。解决方式当然是在eclipse中安装lombok插件啦。 前往官网下载：https://projectlombok.org/download
View Details滚动加载图片（懒加载）实现原理
本文主要通过以下几方面来说明懒加载技术的原理，个人前端小菜，有错误请多多指出 一、什么是图片滚动加载？ 通俗的讲就是：当访问一个页面的时候，先把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 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 |
(function($) { $.fn.scrollLoading = function(options) { var defaults = { // 在html标签中存放的属性名称； attr: "data-url", // 父元素默认为window container: window, callback: $.noop }; // 不管有没有传入参数，先合并再说； var params = $.extend({}, defaults, options || {}); // 把父元素转为jquery对象； var container = $(params.container); // 新建一个数组，然后调用each方法，用于存储每个dom对象相关的数据； params.cache = []; $(this).each(function() { // 取出jquery对象中每个dom对象的节点类型，取出每个dom对象上设置的图片路径 var node = this.nodeName.toLowerCase(), url = $(this).attr(params["attr"]); //重组，把每个dom对象上的属性存为一个对象； var data = { obj: $(this), tag: node, url: url }; // 把这个对象加到一个数组中； params.cache.push(data); }); var callback = function(call) { if ($.isFunction(params.callback)) { params.callback.call(call); } }; //每次触发滚动事件时，对每个dom元素与container元素进行位置判断，如果满足条件，就把路径赋予这个dom元素！ var loading = function() { // 获取父元素的高度 var contHeight = container.outerHeight(); var contWidth = container.outerWidth(); // 获取父元素相对于文档页顶部的距离，这边要注意了，分为以下两种情况； if (container.get(0) === window) { // 第一种情况父元素为window，获取浏览器滚动条已滚动的距离；$(window)没有offset()方法； var contop = $(window).scrollTop(); var conleft = $(window).scrollLeft(); } else { // 第二种情况父元素为非window元素，获取它的滚动条滚动的距离； var contop = container.offset().top; var conleft = container.offset().left; } $.each(params.cache, function(i, data) { var o = data.obj, tag = data.tag, url = data.url, post, posb, posl, posr; if (o) { //对象顶部与文档顶部之间的距离，如果它小于父元素底部与文档顶部的距离，则说明垂直方向上已经进入可视区域了； post = o.offset().top - (contop + contHeight); //对象底部与文档顶部之间的距离，如果它大于父元素顶部与文档顶部的距离，则说明垂直方向上已经进入可视区域了； posb = o.offset().top + o.height() - contop; // 水平方向上同理； posl = o.offset().left - (conleft + contWidth); posr = o.offset().left + o.width() - conleft; // 只有当这个对象是可视的，并且这四个条件都满足时，才能给这个对象赋予图片路径； if ( o.is(':visible') && (post < 0 && posb > 0) && (posl < 0 && posr > 0) ) { if (url) { //在浏览器窗口内 if (tag === "img") { //设置图片src callback(o.attr("src", url)); } else { // 设置除img之外元素的背景url callback(o.css("background-image", "url("+ url +")")); } } else { // 无地址，直接触发回调 callback(o); } // 给对象设置完图片路径之后，把params.cache中的对象给清除掉；对象再进入可视区，就不再进行重复设置了； data.obj = null; } } }); }; //加载完毕即执行 loading(); //滚动执行 container.bind("scroll", loading); }; })(jQuery); |
五、参考： 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）的实现原理
View DetailsVS2017 启动调试出现 无法启动程序“http://localhost:15613” 操作在当前状态中是非法的
调试的时候报这样的错误 解决办法： 工具--选项--调试--常规--启用asp.net的JavaScript调试（chrome和ie）去掉勾选 from:http://www.mamicode.com/info-detail-2349622.html
View Detailswin7下 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
View Details微服务：从设计到部署——七、重构单体应用为微服务
本书主要介绍如何使用微服务构建应用程序，这是本书的第七章，也是最后一章。第一章介绍了微服务架构模式，讨论了使用微服务的优点与缺点。随后的章节讨论了微服务架构的方方面面：使用 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、优先将哪些模块转换为微服务 […]
View Details微服务：从设计到部署——六、选择部署策略
本书主要介绍关于如何使用微服务构建应用程序，这是本书的第六章。第一章介绍了微服务架构模式，讨论了使用微服务的优点与缺点。之后的章节讨论了微服务架构的方方面面：使用 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 […]
View Details