首页 文章 精选 留言 我的

精选列表

搜索[计算机组成原理],共10000篇文章
优秀的个人博客,低调大师

lvs之 lvs原理架构介绍

一、 概念 lvs的术语: Router:GWIP vs:virtual server,director rs:real server CIP:client IP VIP:virtual server IP DIP:ditecter IP(connect with rs) RIP:real server IP 用户请求的IP一定是VIP,否则vs就失去了负载均衡的调度意义 LVS方式的cluster从结构上可分为两部分:前端的负载均衡器(称之为director)和后端的真实服务器(称之为real server)。cluster前端的director将来自外界的请求调度到cluster后端不同的real server去执行。real server负责真正的提供各种应用服务,比如:Web、FTP、Mail等服务。real server的数量可以根据实际需求进行增加、减少。 二、lvs的工作过程 三、lvs的类型 lvs有三种通用标准模型 (1)lvs-nat (网络地址映射) (2)lvs-dr (直接路由) (3)lvs-tun (IP隧道) 3.1、 LVS NAT的特性(实质是多目标的DNAT): 1、RS应该使用私有地址; 2、RS的网关的必须指向DIP; 3、RIP和DIP必须在同一网段内; 4、请求和响应的报文都得经过Director;在高负载场景中,Director很可能成为系统性能瓶颈; 5、支持端口映射; 6、RS可以使用任意支持集群服务的OS; lvs-nat:工作流程如图: 3.2、 LVS DR类型的特性: 1、RS可以使用私有地址;但也可以使用公网地址,此时可以直接通过互联网连入RS以实现配置、监控等; 2、RS的网关一定不能指向DIP; 3、RS跟Dirctory要在同一物理网络内(不能由路由器分隔,因为VS通过封装MAC地址到RS); 4、请求报文经过Directory,但响应报文一定不经过Director 5、不支持端口映射; 6、RS可以使用大多数的操作系统; 由于DR类型中,VS、RS的VIP都是一样,如果在同一网段内会造成地址冲突,因此要解决地址冲突有一下三种方法: 禁止RS响应对VIP的ARP广播请求: 1、在前端路由上实现静态MAC地址VIP的绑定; 前提:得有路由器的配置权限; 缺点:Directory故障转时,无法更新此绑定; 2、arptables 前提:在各RS在安装arptables程序,并编写arptables规则 缺点:依赖于独特功能的应用程序 3、修改Linux内核参数 前提:RS必须是Linux; 缺点:适用性差; 两个参数: arp_announce:定义通告模式 arp_ignore:定义收到arp请求的时响应模式 配置专用路由,以使得响应报文首先通过vip所配置的lo上的别名接口 lvs-dr:工作流程如图 3.2、 lvs-tun:IP隧道 1、RIP、DIP、VIP都得是公网地址; 2、RS的网关不会指向也不可能指向DIP; 3、请求报文经过Directory,但响应报文一定不经过Director; 4、不支持端口映射; 5、RS的OS必须得支持隧道功能; lvs-tun:工作流程如图:也是基于lvs-dr的模型,只不过不同的是,rs和vs不必在同一个物理的网络(实现物理冗余),而是通过隧道技术进行vs和rs间的通信 四、 lvs十个调度算法:rr、wrr、lc、wlc、lblc、lblcr、dh、sh、sed、nq 1.轮叫调度(Round Robin)(简称rr) 2.加权轮叫(Weighted Round Robin)(简称wrr) 3.最少链接(Least Connections)(LC) 4.加权最少链接(Weighted Least Connections)(WLC) 5.基于局部性的最少链接(Locality-Based Least Connections)(LBLC) 6.带复制的基于局部性最少链接(Locality-Based Least Connections with Replication)(LBLCR) 7.目标地址散列(Destination Hashing)(DH) 8.源地址散列(Source Hashing)(SH) 9. 最短的期望的延迟(Shortest Expected Delay Scheduling SED)(SED) 10.最少队列调度(Never Queue Scheduling NQ)(NQ) 最常用的两个算法介绍: 2.加权轮叫(Weighted Round Robin)(简称wrr) 调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。 4.加权最少链接(Weighted Least Connections)(WLC) 在集群系统中的服务器性能差异较大的情况下,调度器采用“加权最少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。 说明: 部分参考http://6638225.blog.51cto.com/6628225/1866241 感谢作者。 文章可以转载,必须以链接形式标明出处。 本文转自 张冲andy 博客园博客,原文链接: http://www.cnblogs.com/andy6/p/7017155.html ,如需转载请自行联系原作者

优秀的个人博客,低调大师

《云安全原理与实践》——导读

**前言**近几年,云计算(Cloud Computing)迅速发展,从美国的亚马逊到我国的阿里云,国内外的云计算服务提供商提供了类型繁多、性价比高的IT服务模式,新的服务类型还在不断推出,并在各行各业得到了广泛应用。云计算是信息技术发展过程中的一次巨大变革,众多国家政府以及大型 IT 企业都制定了云计算发展战略规划,以引领或适应技术变革的趋势。在云计算发展的同时,其安全问题也日益凸显。CSA(Cloud Security Alliance,云安全联盟)在2016年2月发布了《2016 年 12 大顶级云计算安全威胁》,指出了包括数据泄露、系统漏洞、拒绝服务、共享技术等在内的12项云安全威胁,云计算的安全问题逐渐成为制约其快速应用和发展的重要因素。为了让读者全面了解云计算中的安全问题,本书从云计算的基本概念入手,由浅入深地分析了云

优秀的个人博客,低调大师

Docker镜像原理和最佳实践

镜像 传统企业是以交付应用的方式进行发布的,交付应用相当于可执行性程序,其整个应用与环境是分开维护的。随着容器技术的兴起,提出了交付环境的概念。交付环境与交付应用相比,交付的不仅是可执行程序,还交付可执行程序依赖的配置文件、类库甚至是整个文件系统。在Docker语境里面,环境就是镜像。从上图左下角镜像示例图可以看出,镜像本身的组织结构是分层的。其优点是,虽然它包含了所有的依赖,但是发布部署的时候不会显著增加信息的传输量。 镜像的表示分为四部分:红色的部分是镜像中心域名,黄色的部分是镜像命名空间,我们可以根据命名空间进行权限控制等操作,绿色是镜像的名称,每个镜像有一个版本(即标签)。Docker官方的镜像不需要镜像中心的域名,有一些镜像可以省略命名空间。 镜像基本操作 镜像制作——Dockerfile 第一行是一个FROM指令,使用了一个叫a

优秀的个人博客,低调大师

Flink 原理与实现:Session Window

在上一篇文章:Window机制中,我们介绍了窗口的概念和底层实现,以及 Flink 一些内建的窗口,包括滑动窗口、翻滚窗口。本文将深入讲解一种较为特殊的窗口:会话窗口(session window)。建议您在阅读完上一篇文章的基础上再阅读本文。 当我们需要分析用户的一段交互的行为事件时,通常的想法是将用户的事件流按照“session”来分组。session 是指一段持续活跃的期间,由活跃间隙分隔开。通俗一点说,消息之间的间隔小于超时阈值(sessionGap)的,则被分配到同一个窗口,间隔大于阈值的,则被分配到不同的窗口。目前开源领域大部分的流计算引擎都有窗口的概念,但是没有对 session window 的支持,要实现 session window,需要用户自己去做完大部分事情。而当 Flink 1.1.0 版本正式发布时,Fl

优秀的个人博客,低调大师

Flink 原理与实现:Window 机制

Flink 认为 Batch 是 Streaming 的一个特例,所以 Flink 底层引擎是一个流式引擎,在上面实现了流处理和批处理。而窗口(window)就是从 Streaming 到 Batch 的一个桥梁。Flink 提供了非常完善的窗口机制,这是我认为的 Flink 最大的亮点之一(其他的亮点包括消息乱序处理,和 checkpoint 机制)。本文我们将介绍流式处理中的窗口概念,介绍 Flink 内建的一些窗口和 Window API,最后讨论下窗口在底层是如何实现的。 什么是 Window 在流处理应用中,数据是连续不断的,因此我们不可能等到所有数据都到了才开始处理。当然我们可以每来一个消息就处理一次,但是有时我们需要做一些聚合类的处理,例如:在过去的1分钟内有多少用户点击了我们的网页。在这种情况下,我们必须定义一个窗口,

优秀的个人博客,低调大师

React Native运行原理解析

Facebook 于2015年9月15日推出react native for Android 版本, 加上2014年底已经开源的IOS版本,至此RN (react-native)真正成为跨平台的客户端框架。本篇主要是从分析代码入手,探讨一下RN在安卓平台上是如何构建一套JS的运行框架。 一、 整体架构 RN 这套框架让 JS开发者可以大部分使用JS代码就可以构建一个跨平台APP。 Facebook官方说法是learn once, run everywhere, 即在Android 、 IOS、 Browser各个平台,程序画UI和写逻辑的方式都大致相同。因为JS 可以动态加载,从而理论上可以做到write once, run everywhere, 当然要做额外的适配处理。如图: RN需要一个JS的运行环境, 在IOS上直接使用内置的javascriptcore, 在Android 则使用webkit.org官方开源的jsc.so。 此外还集成了其他开源组件,如fresco图片组件,okhttp网络组件等。 RN 会把应用的JS代码(包括依赖的framework)编译成一个js文件(一般命名为index.android.bundle), , RN的整体框架目标就是为了解释运行这个js 脚本文件,如果是js 扩展的API, 则直接通过bridge调用native方法; 如果是UI界面, 则映射到virtual DOM这个虚拟的JS数据结构中,通过bridge 传递到native , 然后根据数据属性设置各个对应的真实native的View。 bridge是一种JS 和 JAVA代码通信的机制, 用bridge函数传入对方module 和 method即可得到异步回调的结果。 对于JS开发者来说, 画UI只需要画到virtual DOM 中,不需要特别关心具体的平台, 还是原来的单线程开发,还是原来HTML 组装UI(JSX),还是原来的样式模型(部分兼容 )。RN的界面处理除了实现View 增删改查的接口之外,还自定义一套样式表达CSSLayout,这套CSSLayout也是跨平台实现。 RN 拥有画UI的跨平台能力,主要是加入Virtual DOM编程模型,该方法一方面可以照顾到JS开发者在html DOM的部分传承, 让JS 开发者可以用类似DOM编程模型就可以开发原生APP , 另一方面则可以让Virtual DOM适配实现到各个平台,实现跨平台的能力,并且为未来增加更多的想象空间, 比如react-cavas, react-openGL。而实际上react-native也是从react-js演变而来。 对于 Android 开发者来说, RN是一个普通的安卓程序加上一堆事件响应, 事件来源主要是JS的命令。主要有二个线程,UI main thread, JS thread。 UI thread创建一个APP的事件循环后,就挂在looper等待事件 , 事件驱动各自的对象执行命令。 JS thread 运行的脚本相当于底层数据采集器, 不断上传数据,转化成UI 事件, 通过bridge转发到UI thread, 从而改变真实的View。 后面再深一层发现, UI main thread 跟 JS thread更像是CS 模型,JS thread更像服务端, UI main thread是客户端, UI main thread 不断询问JS thread并且请求数据,如果数据有变,则更新UI界面。 二、 代码流程 1、JS入口 对于JS开发者来说, 整个RN APP就只有一个JS文件, 而开发者需要编写的就只有如上部分。主要是四个部分: require 所有依赖到的组件, 相当于java中的import 或者 c++ 中的include。 var AwesomeProject = React.createClass 创建APP, 并且在render函数中返回UI界面结构(采用JSX ), 实际经过编译, 都会变成JS 代码, 比如 变成 React.createElement(View,{style:{flex:1}}, var styles = StyleSheet.create({, 创建CSS 样式,实际上会直接当做参数直接反馈到上面的React.createElement AppRegistry.registerComponent('AwesomeProject', () => AwesomeProject); 以上三个更像是参数,这个才是JS 程序的入口。即把当前APP的对象注册到AppRegistry组件中, AppRegistry组件是js module。 接着就等待Native事件驱动渲染JS端定义的APP组件。 2、Native 入口 对于Android 开发者, 普通安卓程序入口是Activity.onCreate()方法 , 主要有三个对象 ReactRootView, Android 标准的FrameLayout对象,另外一个功能是提供react 世界的入口,函数startReactApplication实际调用attachMeasuredRootView触发react世界的初始化。 MyReactPackage, 配置当前APP 需要加载的模块,RN 的JS框架会在初始化阶段就会把native的模块按照配置加载到JS数据结构中(MessageQueue), 从而才能在JS 层即可直接判断native是否支持某个模块。支持三种类型模块配置, native module(实际就是不需要操作View结构的API), view managers(实际是映射到virtual DOM中的View组件), JS module 。 ReactInstanceManager, 构建React世界的运行环境,发送事件到JS世界, 驱动整个React世界运转。 通过builder可以创建不同的React环境, 比如内置js 路径, 开发环境dev的js名字,是否支持调试等。doInBackground会加载指定的JS文件, onPostExecute会调用runApplication接口运行JS APP。 ReactRootView第一次onMeasured计算完成, 然后会利用ReactInstanceManager创建 ReactContext上下文环境。重要的是初始化bridge以及加载js文件, 利用JSBundleLoader方法加载index.android.bundle. 如图 此刻进入JS 世界, 开发者的js 语句连同react js框架层被执行。该步骤最终语句是执行AppRegistry.registerComponent注册一个APP组件,但还没有到开始渲染。 当运行环境准备完毕, 则调用bridge方法运行上步注册的APP组件,触发一连串JS 和 Native相互通信,配合事件驱动, 从而完成native世界的渲染。如图利用bridge方法运行上面注册的JS APP组件的runApplication方法: 3、事件循环 所有的APP在操作系统中, 最终都会使用一个事件循环来运行。 一般来说,JS 开发者只需要开发各个组件对象,监听组件事件, 然后利用framework接口调用render方法渲染组件。 而实际上,JS 也是单线程事件循环,不管是 API调用, virtural DOM同步, 还是系统事件监听, 都是异步事件,采用Observer(观察者)模式监听JAVA层事件, JAVA层会把JS 关心的事件通过bridge直接使用javascriptCore的接口执行固定的脚本, 比如"requrire (test_module).test_methode(test_args)"。此时,UI main thread相当于work thread, 把系统事件或者用户事件往JS层抛,同时,JS 层也不断调用模块API或者UI组件 , 驱动JAVA层完成实际的View渲染。JS开发者只需要监听JS层framework定义的事件即可。如图即JS thread 的消息队列循环: 分析代码可知,消息线程创建于ReactContext环境初始化时, MessageQueueThread.java当中, 该消息队列主要接收系统事件(如 Vsync、timer、doFrame、backkey)、UI事件(如键盘弹起、滚动等)以及 callback事件(JS 的回调函数)。如图即ReactRootView往JS 传递键盘弹出的事件: 而对于Android 开发者, Android 已经为APP创建一个默认的 Main Looper, 不管是Android System 还是JS 事件都是发送到Main thread通过UI渲染出来。如图即是MessageQueueThread.java直接使用主线程Looper。 跟普通APP不同是,此时JS thread相当于work thread, JS会把对应的事件或者数据通过bridge发送到UI thread。 如图即是native Java层收到的JS事件的处理函数: 三、 通信机制 RN框架最主要的就是实现了一套JAVA和 JS通信的方案,该方案可以做到比较简便的互调对方的接口。一般的JS运行环境是直接扩展JS接口,然后JS通过扩展接口发送信息到主线程。但RN的通信的实现机制是单向调用,Native线程定期向JS线程拉取数据, 然后转成JS的调用预期,最后转交给Native对应的调用模块。这样最终同样也可以达到Java和 JS 定义的Module互相调用的目的。 1、JS调用java JS调用java 使用通过扩展模块require('NativeModules')获取native模块,然后直接调用native公开的方法,比如require('NativeModules').UIManager.manageChildren()。 JS 调用require('NativeModules')实际上是获取MessageQueue里面的一个native模块列表的属性, 如: 使用_genModules 加载所有native module到 RemoteModules数组。RemoteModules每项都是一个映射到native module的JS对象。 调用RemoteModules 的方法, 实际是把moduleID、methodId、args放入三个queue保存。 至此, JS端调用完毕, queue中数据要等待Native层通过bridge来取。 native层会在一定条件下触发事件, 通过bridge调用callFunctionReturnFlushedQueue和 invokeCallbackAndReturnFlushedQueue ,得到的返回值就是这三个queue。 bridge会把这三个queue交给parseMethodCalls解析, 然后通过JNI回调函数转发到Java层 m_callback 函数是在bridge初始化的时候设置到c++层, 如: 然后在回调函数中,陆续调用ReactCallback对象的call方法,weakCallback就是java层初始化bridge时传入的NativeModulesReactCallback对象,也就是ReactCallback的子类。 到此,转入Java层. 从native module配置表中,取到对应module和method,并执行。 2、java调用JS 之前ReactInstanceManager 中运行JS APP组件,JAVA 是调用catalystInstance.getJSModule 方法获取JS 对象,然后直接访问对象方法runApplication。实际上getJSModule 返回的是js对象在java层的映射对象。 java层可以调用的JS模块主要在CoreModulesPackage.createJSModules方法配置,有: 如果调用JSModules对象的方法,则会动态代理跳转到(mBridge).callFunction(moduleId, methodId, arguments); 接着调用ReactBridge中声明的JNI 函数,public native void callFunction(int moduleId, int methodId, NativeArray arguments); 通过JS 的require和 apply函数拼接一段JS 代码, 然后用javascriptCore的脚本运行接口执行,并得到返回值。 这样就在JS引擎中运行了一段JS代码并得到返回值,实现了JAVA层到JS层的调用。每次有JAVA对JS的访问, 则在返回值中从JS层的messageQueue.js中抓取之前累积的一堆JS calls。因为JAVA层要把时间同步、 系统帧绘制等事件传递给JS, 因此queue中的JS calls都会在很短的时间内被抓取。 四、 扩展机制 1、 模块扩展(native module)官方文档操作:https://facebook.github.io/react-native/docs/native-modules-android.html#content 2、 组件扩展(UI component)官方文档操作:https://facebook.github.io/react-native/docs/native-components-android.html#content 因为react模块加载主要在ReactPackage类配置,因此扩展可以通过反射、外部依赖注入等机制,可以做到跟H5容器一样实现动态插拔的插件式扩展。比如API扩展, 通过外部传入扩展模块的类名即可反射构造函数创建新的API: @Override public List<NativeModule> createNativeModules(ReactApplicationContext reactContext) { List<NativeModule> modules = new ArrayList(); modules.addAll(Arrays.<NativeModule>asList( new AsyncStorageModule(reactContext), new FrescoModule(reactContext), new NetworkingModule(reactContext), new WebSocketModule(reactContext), new ToastModule(reactContext))); if (mModuleList != null && mModuleList.size() > 0) { for (int i = 0; i < mModuleList.size(); i++) { try { Log.i("MyReactPackage", "add Module:" + mModuleList.get(i)); Class c = Class.forName(mModuleList.get(i)); Class[] parameterTypes = {ReactApplicationContext.class}; java.lang.reflect.Constructor constructor = c.getConstructor(parameterTypes); Object[] parameters = {reactContext}; NativeModule module = (NativeModule) constructor.newInstance(parameters); modules.add(module); }catch (Exception e) { Log.i("MyReactPackage", "add Module Exeception:" + e); e.printStackTrace(); } } } return modules; } 五、 离线加载 代码离线 离线包支持。 目前RN官方支持内置APK打包以及dev server在线更新。而实际上,一般的容器都会实现一套离线包发布平台。大致的实现方案是自定义一个JSBundleLoader,对接到应用管理发布平台。 分离react 框架代码和应用业务代码。目前官方的生产工具是把框架代码和业务代码弄成一个bundle。 但框架代码很大,需要共用, 因此要分离出框架代码单独前置加载。 应用业务代码变成很小一段JS代码单独发布。如果每次都加载框架代码, 启动业务代码会比较慢,一个helloworld都需要4秒左右。初步实践方案是把ReactInstanceManager设置成全局变量共享,在Native APP 启动初始化或者第一次进入RN APP时初始化ReactInstanceManager。这个可能会导致多个RN APP全局变量冲突。 在线更新离线包更新主要依赖应用管理发布平台,大致可以做到跟H5离线包一致。 资源离线 一般说的是图片资源比较多, RN 使用控件显示图片,如: 通过source属性设置图片资源路径, 映射到native层: 因此不管是离线包内资源还是系统资源,只要能转换成Android 统一资源定位URI对象,即可获取到图片。 在线资源 如果是静态资源,则直接URI统一定位。如果是动态资源, 比如要通过网关获取到base64格式的图片,则需要native扩展特别接口。 六、 总结 1、 可能瓶颈 * 因为bridge, JS和 JAVA是异步互通,如果实现复杂多API的逻辑,可能会导致部分效率损耗在多线程通信。JS 异步的编程方式多多少少带来一些不便。 * 因为bridge, 可能某些场景做不到及时响应。比如帧动画的实时控制。 * Android版本刚推出不完善,并且目前RN版本还在不停的更新中, 可能存在暗坑。 * 加入JS引擎, 内存的控制比较麻烦,会比普通native增加不少。 2、 待研究 动态注入的API插件实现方案,能跟h5容器共用实现。 因为RN已经具备很多的灵活, JS也可以做到很多大型控件,所以native UI扩展需要定义JS 和 native边界, 哪些是JS 实现, 哪些是native实现。 动画的实现方式。 H5容器和RN容器融合方案 write once, 完全跨平台。 JS 层支持 Fragment manager 性能比较数据 Demo还在实现当中,等抓完再补充。 环境搭建

资源下载

更多资源
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题,腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构,目前腾讯云软件源站支持公网访问和内网访问。

Spring

Spring

Spring框架(Spring Framework)是由Rod Johnson于2002年提出的开源Java企业级应用框架,旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念,提供核心容器、应用上下文、数据访问集成等模块,支持整合Hibernate、Struts等第三方框架,其适用范围不仅限于服务器端开发,绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源,继承了IntelliJ IDEA强大的JS部分的功能。

用户登录
用户注册