• 关于

    调度操作工作原理

    的搜索结果

回答

(1)线程的工作场景主要有两条: 一个是并发操作,避免阻塞和更有效利用资源。典型的例子有:在长时间工作的程序中使用工作线程避免界面失去响应。在网络下载程序中,使用多个线程提高对网络的使用效率,更快下载文件。 一个是并行,线程是处理器调度的最小单位。如果你的计算机配置了多个处理器或者内核,那么可以同时利用多个处理器同时计算,加快问题解决的速度。 (2)多线程的工作原理: 对于单处理器系统,操作系统会轮流调度每个线程执行一小段时间,然后切换另一个线程,在切换的时候,保存当前线程使用的寄存器上下文和堆栈,并且在下次调度的时候恢复。这样线程中的程序感觉不到自己被中断过。对于多处理器系统,操作系统会将不同的线程调度给多个处理器,让它们并行执行。

蛮大人123 2019-12-02 01:50:45 0 浏览量 回答数 0

问题

请问安卓系统内部是这样运作的?操作原理是什么?

爵霸 2019-12-01 19:56:30 893 浏览量 回答数 1

回答

说实话这乱七八糟一堆文字我看了两边,然后发现真救不了你. ######回复 @刘子玄:操作系统不管理寄存器,现在都是抢占式多线程操作系统,都是在线程释放资源的时候切换到其他进程的(你调用某些api的时候会发生等待和切换操作,然后保存线程执行环境数据)看一下操作系统原理的书籍就知道了.直接切换那个只有纯正的分时操作系统才会去做.现在估计只剩下大型UNIX了######==######靠时钟中断,硬件一定会定时发起时钟中断,中断服务一定会执行,这样就可以进行调度或做其他事了,中断机制由硬件保证。找书看吧,这些问题不是几句说得清。######谢了######在中断产生时,寄存器压栈,在中断结束后,堆栈的数据弹回到寄存器。###### 寄存器操作是汇编级别的最小操作单元,即使是操作系统也不能够管理寄存器. 是计算机有一些指令,能够自己把所有寄存器保存到一个地方.######计算机基础如此博大精深,几十年高科技结晶,不是三天三夜就能说清的,更何况几句话###### 简单2个字压栈.OS的原理很简单,你可以找一些嵌入式的OS开源代码进行阅读,相信读完2个系统的代码后,就对OS核心部分很清楚了. 挑你的一个问题进行回答:" 操作系统是如何让一个程序在规定时间内执行再准确的暂停了?这是如何控制的?"      感觉你还不清楚调度算法的实现.简单的说:硬件中断将其打断,如果需要1ms的进程调度精度,那么就设置时钟中断为1ms. 你可以看下中断部分的代码.       CPU的PC指针即使软件不去设置它也不是固定不变只能向下跑的.当中断发生的时候,PC指针会自动修改到相应中断向量的物理地址上,并且中断时的重要寄存器的值被硬件自动保存. 于是我们就设置一个时钟中断向量(将这个地址上写入我们的代码函数的地址),每18msPC指针会被自动改到这个地方,在这个地方我们根据调度算法,看是继续执行被打断的线程还是切换到更合适的线程上.  感性上,线程/cpu的运行实际上是非常的不连贯, 中途不断的被各种中断疯狂的打断.尤其高响应的硬实时OS,打断应该更加频繁. 我们想干任何事情都可以在中断处理中去做.        此外除了硬件中断,因为硬件功能都是api提供,so程序代码实际上经常会很频繁调用一些系统API,既然调用了系统api,os也完全可以在系统api执行软中断,执行调度算法,把pc指针移到别处去,不再正常的函数返回了(保存好数据,下次调度它时,模拟这个函数返回,应用程序完全不知道发生了什么). ######一个嵌入式OS的代码不过几千行而已. 看完几个 你就精通OS的实现了.不过"知识改变命运", 懂得越多混得越惨, 个人建议你干点其他能赚钱的事情.底层实现的东西,除了吹牛,提升点技术素质,对赚钱来说毫无用处,面试时都没用!!(实际上现在面试都是看算法)  小正太, 根据赚钱来指导自己学习/背诵什么东西.(很心痛的经验)######回复 @MinGKai:haha.反正比赚1个亿简单多了.######“精通”OS有那么简单么…………######这个你放心,我只会把编程当成毕生的爱好,而不会用作工作。

优选2 2020-06-09 16:14:52 0 浏览量 回答数 0

阿里云试用中心,为您提供0门槛上云实践机会!

0元试用32+款产品,最高免费12个月!拨打95187-1,咨询专业上云建议!

回答

说实话这乱七八糟一堆文字我看了两边,然后发现真救不了你. ######回复 @刘子玄 : 操作系统不管理寄存器,现在都是抢占式多线程操作系统,都是在线程释放资源的时候切换到其他进程的(你调用某些api的时候会发生等待和切换操作,然后保存线程执行环境数据)看一下操作系统原理的书籍就知道了.直接切换那个只有纯正的分时操作系统才会去做.现在估计只剩下大型UNIX了######= =######靠时钟中断,硬件一定会定时发起时钟中断,中断服务一定会执行,这样就可以进行调度或做其他事了,中断机制由硬件保证。找书看吧,这些问题不是几句说得清。######谢了######在中断产生时,寄存器压栈,在中断结束后,堆栈的数据弹回到寄存器。###### 寄存器操作是汇编级别的最小操作单元,即使是操作系统也不能够管理寄存器. 是计算机有一些指令,能够自己把所有寄存器保存到一个地方. ######计算机基础如此博大精深,几十年高科技结晶,不是三天三夜就能说清的,更何况几句话###### 简单2个字 压栈. OS的原理很简单, 你可以找一些嵌入式的OS开源代码进行阅读, 相信读完2个系统的代码后, 就对OS核心部分很清楚了. 挑你的一个问题进行回答: "操作系统是如何让一个程序在规定时间内执行再准确的暂停了?这是如何控制的?"       感觉你还不清楚调度算法的实现.简单的说: 硬件中断将其打断,如果需要1ms的进程调度精度,那么就设置时钟中断为1ms.  你可以看下中断部分的代码.        CPU的PC指针即使软件不去设置它也不是固定不变只能向下跑的. 当中断发生的时候,PC指针会自动修改到相应中断向量的物理地址上,并且中断时的重要寄存器的值被硬件自动保存.  于是我们就设置一个时钟中断向量(将这个地址上写入我们的代码函数的地址), 每18ms PC指针会被自动改到这个地方,在这个地方 我们根据调度算法, 看是继续执行被打断的线程 还是切换到更合适的线程上.   感性上, 线程/cpu 的运行 实际上是非常的不连贯,  中途不断的被各种中断疯狂的打断. 尤其高响应的硬实时OS,打断应该更加频繁.  我们想干任何事情都可以在中断处理中去做.         此外除了硬件中断, 因为硬件功能都是api提供,so程序代码实际上经常会很频繁调用一些系统API, 既然调用了系统api, os也完全可以在系统api执行软中断, 执行调度算法, 把pc指针移到别处去, 不再正常的函数返回了(保存好数据, 下次调度它时,模拟这个函数返回, 应用程序完全不知道发生了什么). ######一个嵌入式OS的代码不过几千行而已.  看完几个  你就精通OS的实现了. 不过"知识改变命运",  懂得越多混得越惨,  个人建议你干点其他能赚钱的事情. 底层实现的东西, 除了吹牛, 提升点技术素质, 对赚钱来说毫无用处, 面试时都没用!! (实际上现在面试都是看算法)   小正太,  根据赚钱来指导自己学习/背诵 什么东西. (很心痛的经验)######回复 @MinGKai : haha. 反正比赚1个亿简单多了.######“精通”OS有那么简单么…………######这个你放心,我只会把编程当成毕生的爱好,而不会用作工作。

爱吃鱼的程序员 2020-05-30 22:45:50 0 浏览量 回答数 0

回答

代表你的基础已经很好了,嵌入式学习相关的基础知识主要是这些: 一是程序设计的基础,例如:基本的编程语言基础,至少对数据类型、程序的结构及流程控制等最基本的内容要相当清楚,所以建议恶补一下C语言,推荐谭浩强的C语言程序设计,好好看一下,呵呵。另外有不少同学都问到数据结构的基础,我一直认为数据结构和算法的学习是帮助形成程序设计逻辑思维的很好训练方式,对于程序员的长期专业素养的提高一定有好处,所以建议即使已经在嵌入式行业中工作之后也应该多补充一些相关的知识。许多在学校没有学过数据结构的同学往往认为这部分非常枯燥、难学。而实际上如果你能明白研究计算机存储和数据组织方式的意义,就一定能够充分体会到数据结构的价值和魅力。一旦兴趣有了,一切就会迎刃而解,呵呵。 二是操作系统工作原理,这部分往往是非计算机专业的同学在学校时没有接触过的。而由于嵌入式软件设计相关的多任务环境、模块间的同步与通信协同、驱动设计等往往都需要有对操作系统工作机制的了解和掌握作为基础,因此建议没有系统学习过的同学,找一本相关的操作系统工作原理书籍认真看一下(不用特厚、特专业、特内核的,先以普及知识为主,呵呵。)。 三是基本的硬件基础,由于嵌入式Linux开发往往是ARM+Linux路线,所以为了能够在后续学习过程中很好地掌握主流嵌入式微处理器的结构与原理(例如:ARM9),就需要对硬件工作原理有初步的了解和掌握,建议看一下诸如计算机组成原理、体系结构等相关的专业书籍。 要深入学习你可以尝试以下路线: (1) C语言是所有编程语言中的强者,单片机、DSP、类似ARM的种种芯片的编程都可以用C语言搞定),因此必须非常熟练的掌握。 推荐书籍:《The C Programming Language》 这本经典的教材是老外写的,也有中译版本。 (2) 操作系统原理,是必需的,如果你是计算机专业毕业那也就无所谓了,如果是非计算机专业的就必须找一本比较浅显的计算机原理书籍看一看,把啥叫“进程”“线程”“系统调度”等等基本问题搞清楚。 (3)Linux操作系统就是用C语言编写的,所以你也应该先学习下Linux方面的编程,只有你会应用了,才能近一步去了解其内核的精髓。 推荐书籍:《UNIX环境高级编程》(第2版) (4) 了解ARM的架构,原理,以及其汇编指令,我们在嵌入式开发中,一般很少去写汇编,但是最起码的要求是能够看懂arm汇编。 (5) 系统移植的时候,就需要你从最下层的bootloader开始,然后内核移植,文件系统移植等。而移植这部分对硬件的依赖是非常大的,其配置步骤也相对复杂,也没有太多详细资料。 (6) 驱动开发 linux驱动程序设计既是个极富有挑战性的领域,又是一个博大精深的内容。 linux驱动程序设计本质是属于linux内核编程范畴的,因而是对linux内核和内核编程是有要求的。在学习前你要想了解linux内核的组成,因为每一部分要详细研究的话足够可以扩展成一本厚书。 以上只不过是大概的框架,在实际的开发中还会涉及很多东西,比如:交叉编译、makefile、shell脚本等等,所以说学习嵌入式的周期较长,门槛较高,自学的话更是需要较强的学习能力和专业功底。只要能坚持下来一定会取得成功。 华清远见的嵌入式专业教材比较专业,也很出名,高校图书馆以及外面书店都有卖,你可以去网上搜一下,买本看看,华清远见的网站和技术论坛上面也有很多嵌入式学习资料和视频可以下载,而且更新的速度也很快,LZ没事可以去转转,相信对你会有帮助。 另外,虚机团上产品团购,超级便宜-------------------------推荐使用:Linux 高级程序设计(第二版)杨宗德 邓玉春编著 这本书不仅讲述linux常使用的函数,同时对整体的系统结构分析都比较好,例如内存管理,多进程等等

琴瑟 2019-12-02 01:19:56 0 浏览量 回答数 0

问题

【精品问答】130+大数据面试汇总

问问小秘 2019-12-01 21:52:42 1644 浏览量 回答数 2

问题

【精品问答】大数据计算技术1000问

问问小秘 2019-12-01 21:57:13 6895 浏览量 回答数 2

问题

【教程免费下载】 VMware vSphere性能设计:性能密集场景下CPU、内存

沉默术士 2019-12-01 22:07:47 1680 浏览量 回答数 1

回答

回1楼hjytub2的帖子 centos 5.4 32 系统自带的? ------------------------- Re张华是谁?/usr/src/张华简历.pdf 个人简历 基本资料: 姓 名: 张华 性 别: 男 年 龄: 24 籍 贯: 宁夏银川 毕业院校: 西安邮电大学 专 业: 软件工程 学 历: 本科 移动电话: 18358154585 E-mail: zhanghuaEC2@126.com 职位意向 云存储,虚拟化存储开发,虚拟化,或云计算其他研发职位 个人爱好 热爱计算机技术,关注云计算,酷爱足球,关注足球赛事,热爱文学 技能与实践 � 熟悉虚拟化相关理论知识,熟练操作并运用 XEN 虚拟机。 能够源码编 译安装 XEN 虚拟机,能够开发并实施虚拟机的场景化。 � 熟悉虚拟机的网络相关知识, 具有良好的计算机网络基础。 熟悉云安全, 精通 iptables,arptable 和 ebtables,尝试构建过弹性计算分布式防 火墙。熟悉思科 N2K,N5K,N7K 以及 F5 等网络设备。熟悉 vlan。 � 熟悉文件系统相关知识, 熟悉虚拟机存储相关知识, 阅读过 XEN blktap2 框架代码,并且能基于 tapdisk 数据结构开发用户态文件系统。曾经利 用 hadoop hdfs 和 blktap2 框架开发分布式的虚拟机镜像存储文件系统。 熟悉虚拟机的快照功能的设计和实现。阅读过 vhd 实现源代码。 � 了解分布式存储文件系统, 熟悉 hadoop 和 hbase, 深入学习并了 解 hadoop 文件系统架构和原理。Hbase 组织和架构正在学习中,能够搭建 NFS,NBD 文件系统。 � 具有一定的云计算资源调度,分布式通信,分布式锁,分布式命名服务 理论基础。 � 精通 C 语言,C  ,具有良好的数据结构基础,学习过 erlang 语言。 � 具有两年的 linux 操作系统使用经验, 熟悉 Shell 脚本编程, 熟悉 python 语言以及 php,熟悉 Linux 下 C 编程,熟悉进程间通信。 � 具有良好的操作系统基础。具备一定的内核基础知识。 工作经历: 1. 2011-11 月-至今:就职于阿里云计算有限公司后羿弹性计算团队,负 责生产集群上虚拟机存储运维工作。 个人简介 具有良好的自学能力和动手操作能力, 渴望知识, 热爱技术。 乐观向上, 敢于承担压力。具有良好的沟通能力和团队意识。生活认真热情,富责 任心。为人坦诚、守信。适应新思维、新方式。 ------------------------- 回10楼shuguang的帖子 没有被黑,简历是阿里云的人 ------------------------- 回7楼cloudlu的帖子 那是我的主机被人黑了……然后就放了一个简历啊……而且简历内容刚好是你们阿里云内部人的啊? 主机刚重置系统不到30小时

lixin0598 2019-12-01 23:48:26 0 浏览量 回答数 0

回答

本文主要介绍虚拟节点和ECI,以及如何通过Virtual Node Addon插件部署虚拟节点创建ECI Pod。 虚拟节点和弹性容器实例ECI 阿里云弹性容器实例ECI(Elastic Container Instance)是面向容器的无服务器弹性计算服务,提供免运维、强隔离、快速启动的容器运行环境。使用ECI无需购买和管理底层 ECS 服务器,让用户更加关注在容器应用而底层基础设施的维护工作。用户可按需创建ECI,仅为容器配置的资源付费(按量按秒计费)。 虚拟节点Virtual Node来源于Kubernetes社区的Virtual Kubelet技术,其实现了Kubernetes与弹性容器实例ECI的无缝连接,让 Kubernetes 集群轻松获得极大的弹性能力,而不必受限于集群的节点计算容量。关于Virtual Kubelet的工作原理及其架构,请参见Virtual Kubelet 因为Virtual Node可以轻松支持更高弹性和Pod容量,灵活动态的按需创建ECI Pod,免去集群容量规划的麻烦,所以它非常适合运行在如下多个场景,帮助用户极大降低计算成本,提升计算弹性效率。 在线业务的波峰波谷弹性伸缩:如在线教育、电商等行业有着明显的波峰波谷计算特征。使用虚拟节点可以显著减少固定资源池的维护,降低计算成本。 数据计算:使用虚拟节点承载Spark、Presto等计算场景,有效降低计算成本。 CI/CD Pipeline:Jenkins、Gitlab-Runner。 Job任务:定时任务、AI。 阿里云容器服务基于虚拟节点和ECI提供了多种Serverless Container产品形态,包括Serverless Kubernetes(ASK)和ACK on ECI,充分支撑各种弹性和免节点运维场景的用户诉求。virtual node 在ACK集群中部署虚拟节点Addon 说明 在Serverless Kubernetes集群中我们无需手动部署虚拟节点Addon,用户可以直接创建ECI Pod。托管版或专属版则需要先部署ack-virtual-node addon后才可以创建ECI Pod。 在容器服务Kubernetes版(ACK)集群中部署虚拟节点Addon前, 您需要创建一个 Kubernetes 托管版或者专属版集群。详情请参见创建 Kubernetes 托管版集群。 您需要开通弹性容器实例服务。登录弹性容器实例控制台开通相应的服务。 您需要确认集群所在区域在ECI支持的地域列表内。登录弹性容器实例控制台查看已经支持的地域和可用区。 登录容器服务管理控制台。 在控制台左侧导航栏中,单击市场 > 应用目录,并在右侧选中ack-virtual-node。 在应用目录-ack-virtual-node页面,单击参数,配置虚拟节点参数。 参数 参数含义 获取路径 ECI_REGION 地域名称 您可以在集群基本信息的基本信息区域中,获取地域的值。 说明 例如,华东1:cn-hangzhou ECI_VPC 集群的VPC 您可以在集群基本信息的集群资源区域中,获取虚拟专有网络 VPC的值。 ECI_VSWITCH 虚拟交换机 您可以在节点列表单击某个节点,在实例详情页签的配置信息区域中,获取虚拟交换机的值。 说明 请确认当前交换机在ECI支持的可用区列表中。 虚拟交换机支持多可用区。因此,这里可以填写多个vSwitch,例如ECI_VSWITCH: "vsw-xxxxxxx1, vsw-xxxxxxx2, vsw-xxxxxxx3"。 ECI_SECURITY_GROUP 安全组ID 您可以在节点列表单击某个节点,在本实例安全组页签的安全组列表区域中,获取安全组ID的值。 ECI_ACCESS_KEY 用户AccessKey 请参见如何获取AccessKey。 ECI_SECRET_KEY 用户SecretKey 请参见如何获取AccessKey。 ALIYUN_CLUSTERID 集群ID 您可以在集群基本信息的基本信息区域中,获取集群ID的值。 配置完成后,在右侧的创建页面,选择对应的集群,可以看到命名空间已设定为kube-system,发布名称已设定为ack-virtual-node,单击创建。创建插件 安装完成后,在控制台左侧导航栏中,单击集群 > 节点,在节点列表页面可以看到添加了虚拟节点virtual-node-eci。添加节点 执行以下命令查看virtual-node-controller和virtual-node-admision-controller部署状态。详情请参见在CloudShell上通过kubectl管理Kubernetes集群。 kubectl -n kube-system get statefulset virtual-node-eci NAME READY AGE virtual-node-eci 1/1 1m kubectl -n kube-system get deploy ack-virtual-node-affinity-admission-controller NAME READY UP-TO-DATE AVAILABLE AGE ack-virtual-node-affinity-admission-controller 1/1 1 1 1m kubectl -n kube-system get pod|grep virtual-node-eci virtual-node-eci-0 1/1 Running 0 1m kubectl get no|grep virtual-node-eci virtual-node-eci-0 Ready agent 1m v1.11.2-aliyun-1.0.207 调度Pod到虚拟节点 说明 此操作不适用于Serverless Kubernetes集群。 当集群中存在虚拟节点时,您可以把Pod调度到虚拟节点上,Virtual Node Controller将会创建出相应的ECI Pod。您可以通过以下三种方法操作。 配置Pod的nodeSelector和tolerations。 虚拟节点有特殊的Taints,Pod需要配置nodeSelector和tolerations后才能指定调度到虚拟节点上。示例如下: apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx imagePullPolicy: Always name: nginx nodeSelector: type: virtual-kubelet tolerations: - key: virtual-kubelet.io/provider operator: Exists 配置Pod标签。 基于virtual-node-affinity-admission-controller的webhook,对于有特定label(eci=true)的Pod,webhook会将其自动调度到虚拟节点上。示例如下: kubectl run nginx --image nginx -l eci=true kubectl get pod -o wide|grep virtual-node-eci nginx-7fc9f746b6-r4xgx 0/1 ContainerCreating 0 20s 192.168.1.38 virtual-node-eci-0 配置Namespace标签。 基于virtual-node-affinity-admission-controller的webhook,对于有特定label的namespace(virtual-node-affinity-injection=enabled)中创建的Pod,webhook会将其自动调度到虚拟节点上。示例如下: kubectl create ns vk kubectl label namespace vk virtual-node-affinity-injection=enabled kubectl -n vk run nginx --image nginx kubectl -n vk get pod -o wide|grep virtual-node-eci nginx-6f489b847d-vgj4d 1/1 Running 0 1m 192.168.1.37 virtual-node-eci-0 修改虚拟节点Controller的配置 说明 此操作不适用于Serverless Kubernetes集群。 虚拟节点Controller的配置决定了其调度ECI Pod的行为和ECI运行环境配置,包括vswitch和安全组配置等。我们可以根据需要灵活的修改Controller配置,修改配置后不会影响已经运行的ECI Pod,会立即生效于新建ECI Pod。 修改虚拟节点Controller配置的方法如下。 kubectl -n kube-system edit statefulset virtual-node-eci 常用的变更操作如下。 更新virtual-node controller版本。 当需要使用更新虚拟节点功能时,需要更新virtual-node controller镜像至最新版本。例如支持ECI Pod clusterIP访问的vk镜像版本需要高于v1.0.0.2-aliyun。 修改安全组配置ECI_SECURITY_GROUP。 用户可以修改此环境变量,改变ECI Pod的安全组。 修改vswitch配置ECI_VSWITCH。 用户可以修改此环境变量,改变ECI Pod所在的vswitch。我们建议用户配置多个vswitch支持多可用区,这样当单可用区库存不足时,Controller会选择另外一个可用区创建ECI Pod。 修改kube-proxy配置ECI_KUBE_PROXY。 此环境变量默认值为true,表示ECI Pod默认可以访问集群中的ClusterIP Service。如果ECI Pod无需访问clusterIP service时,例如Job计算场景,用户可以设置此环境变量为false关闭kube-proxy功能。另外在一些规模化场景,例如集群中需要启动大量ECI Pod时,ECI中的kube-proxy和kubernetes apiserver之间的并发连接数也会大量增加,用户同样可以选择关闭kube-proxy功能,减少对apiserver的压力提升可扩展性,改用privatezone方式让ECI Pod访问集群中的service。 创建多个虚拟节点。 我们推荐使用单个虚拟节点支撑3000个ECI Pod,当需要创建更多ECI Pod时,可以创建更多的虚拟节点,这样集群中能够支撑的ECI Pod数量也会相应成倍增长。方法是修改statefulset的副本数量,其数量代表集群中虚拟节点的数量,virtual-node-controller pod与虚拟节点一一对应,分别管理虚拟节点上的ECI Pod,controller之间互不影响。所示如下: kubectl -n kube-system scale statefulset virtual-node-eci --replicas=4 statefulset.apps/virtual-node-eci scaled kubectl get no NAME STATUS ROLES AGE VERSION cn-hangzhou.192.168.1.1 Ready 63d v1.12.6-aliyun.1 cn-hangzhou.192.168.1.2 Ready 63d v1.12.6-aliyun.1 virtual-node-eci-0 Ready agent 6m v1.11.2-aliyun-1.0.207 virtual-node-eci-1 Ready agent 1m v1.11.2-aliyun-1.0.207 virtual-node-eci-2 Ready agent 1m v1.11.2-aliyun-1.0.207 virtual-node-eci-3 Ready agent 1m v1.11.2-aliyun-1.0.207 删除虚拟节点 说明 此操作不适用于Serverless Kubernetes集群。 通常情况下我们无需删除虚拟节点,虚拟节点不同与真实节点,不会占用集群计算资源。如果用户需要删除虚拟节点,我们建议手动先驱逐虚拟节点上的Pod,或者删除所有ECI Pod,然后删除Controller和节点。在ECI Pod存在时删除virtual-node controller可能会导致ECI实例的残留。 kubectl drain virtual-node-eci-0 ... kubectl -n kube-system delete statefulset virtual-node-eci kubectl delete no virtual-node-eci-0 ...

1934890530796658 2020-03-31 20:20:53 0 浏览量 回答数 0

回答

简介 本文介绍如何将已有的Kubernetes应用迁移到基于ECI的Serverless Kubernetes或者虚拟节点扩展。希望能帮助您了解在迁移到ECI中需要进行的适配和改造,并帮助您解决部分在迁移应用中可能会遇到的问题。 假设 本文假设您对Kubernetes的基本概念已经有所了解,或者已经在私有云或者公有云中使用过基于Kubernetes的容器编排服务。 迁移前的准备工作 您可以通过Serverless Kubernetes简介 和 虚拟节点扩展 了解ECI与Kubernetes对接的基本原理。 您无需提前创建ECI实例,只需要提前创建好Serverless Kubernetes集群,或者在已有的Kubernetes托管版中部署好Virtual Node Addon。 如何管理Kubernetes及ECI运行情况 您可以通过容器服务控制台来操作Serverless Kubernetes集群和Kubernetes托管版集群。 您可以通过阿里云提供的CloudShell来管理Kubernetes集群。 您可以通过kubectl客户端在本地计算机来访问远端的Kubernetes集群。详情请参考这里。 如何查看已经创建的ECI实例 进入弹性容器实例控制台,在左上角选择相应的可用区,您可以看到已经创建的ECI实例。如果您看到的是空白页面,请申请弹性容器实例页面的访问权限。 进入容器服务控制台,从左侧导航栏中点击‘应用’>‘容器组’,选择对应的集群和namespace,可以查看到已有的pod,被调度到virtual-kubelet节点上的即是ECI实例,点击实例的‘详情’可以查看详细信息。 eci-pod 应用迁移的限制 virtual-kubelet是作为一个虚拟节点对接Kubernetes,因此ECI实例并不会跑在一个集中式的“真实”节点上,而是会被打散分布在整个阿里云的资源池中。 考虑到公有云的安全性和虚拟节点本身带来的限制,ECI目前还不支持Host相关功能以及DaemonSet。具体如下: 不支持的功能 具体内容 备选方案 HostPath Mount本地宿主机文件到容器中 使用emptyDir,或者NAS存储 HostNetwork 将宿主机端口映射到容器中 使用type=LoadBalancer的负载均衡 DaemonSet 在容器所在宿主机上部署static pod 通过sidecar形式在pod中部署多个镜像 Privileged权限 容器拥有privileged权限 使用secretContext为pod添加Capability type=NodePort的Service 通过宿主机端口映射到容器端口 使用type=LoadBalancer的负载均衡 应用迁移的说明 Kubernetes集群和Serverless Kubernetes共享容器镜像仓库,因此可以将容器镜像先上传到容器镜像仓库中。为了加速镜像的拉取,建议使用专有网络的镜像地址(registry-vpc.xxx)。 Serverless Kubernetes和虚拟节点扩展 支持 Deployment, ReplicaSet,Job,Cronjob,StatefulSet等常见controller,理论上可以直接运行。 Serverless Kubernetes和虚拟节点扩展 利用 PrivateZone 实现 服务发现,因此建议在创建集群时默认勾选 PrivateZone支持。 Serverless Kubernetes和虚拟节点扩展 支持 type=LoadBalancer 的Service。您可以将Service修改为type=LoadBalancer,详情请参考这里。 apiVersion: v1 kind: Service metadata: labels: app: nginx name: nginx namespace: default spec: externalTrafficPolicy: Cluster ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx sessionAffinity: None type: LoadBalancer

1934890530796658 2020-03-20 17:23:03 0 浏览量 回答数 0

问题

Accordion:HBase一种内存压缩算法

pandacats 2019-12-18 16:06:15 1 浏览量 回答数 0

问题

【教程免费下载】深入浅出DPDK

玄学酱 2019-12-01 22:07:40 2817 浏览量 回答数 0

回答

一 容器 在学习k8s前,首先要了解和学习容器概念和工作原理。 什么是容器? 容器是一种轻量级、可移植、自包含的软件打包技术,使应用程序可以在几乎任何地方以相同的方式运行。开发人员在自己笔记本上创建并测试好的容器,无需任何修改就能够在生产系统的虚拟机、物理服务器或公有云主机上运行。 容器的优势 容器使软件具备了超强的可移植能力。 对于开发人员 – Build Once, Run Anywhere 容器意味着环境隔离和可重复性。开发人员只需为应用创建一次运行环境,然后打包成容器便可在其他机器上运行。另外,容器环境与所在的 Host 环境是隔离的,就像虚拟机一样,但更快更简单。 对于运维人员 – Configure Once, Run Anything 只需要配置好标准的 runtime 环境,服务器就可以运行任何容器。这使得运维人员的工作变得更高效,一致和可重复。容器消除了开发、测试、生产环境的不一致性。 Docker概念 “Docker” 一词指代了多个概念,包括开源社区项目、开源项目使用的工具、主导支持此类项目的公司 Docker Inc. 以及该公司官方支持的工具。技术产品和公司使用同一名称,的确让人有点困惑。 我们来简单说明一下: IT 软件中所说的 “Docker” ,是指容器化技术,用于支持创建和使用容器。 开源 Docker 社区致力于改进这类技术,并免费提供给所有用户,使之获益。 Docker Inc. 公司凭借 Docker 社区产品起家,它主要负责提升社区版本的安全性,并将技术进步与广大技术社区分享。此外,它还专门对这些技术产品进行完善和安全固化,以服务于企业客户。 借助 Docker,您可将容器当做轻巧、模块化的虚拟机使用。同时,您还将获得高度的灵活性,从而实现对容器的高效创建、部署及复制,并能将其从一个环境顺利迁移至另一个环境,从而有助于您针对云来优化您的应用。 Docker有三大核心概念: 镜像(Image)是一个特殊的文件系统,提供容器运行时所需的程序、库、配置等,构建后不会改变 容器(Container)实质是进程,拥有自己独立的命名空间。 仓库(Repository)一个仓库可以包含多个标签(Tag),每个标签对应一个镜像 容器工作原理 Docker 技术使用 Linux 内核和内核功能(例如 Cgroups 和 namespaces)来分隔进程,以便各进程相互独立运行。这种独立性正是采用容器的目的所在;它可以独立运行多种进程、多个应用,更加充分地发挥基础设施的作用,同时保持各个独立系统的安全性。 二 Kubernetes入门知识指南 Kubernets的知识都可以在官方文档查询,网址如下: https://kubernetes.io/zh/docs/home/ Kubernetes基础知识 Kubernetes是什么? Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。 为什么需要 Kubernetes 容器是打包和运行应用程序的好方式。在生产环境中,您需要管理运行应用程序的容器,并确保不会停机。例如,如果一个容器发生故障,则需要启动另一个容器。如果由操作系统处理此行为,会不会更容易? Kubernetes 为您提供: 服务发现和负载均衡 Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果到容器的流量很大,Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。 存储编排 Kubernetes 允许您自动挂载您选择的存储系统,例如本地存储、公共云提供商等。 自动部署和回滚 您可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态更改为所需状态。例如,您可以自动化 Kubernetes 来为您的部署创建新容器,删除现有容器并将它们的所有资源用于新容器。 自动二进制打包 Kubernetes 允许您指定每个容器所需 CPU 和内存(RAM)。当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。 自我修复 Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。 密钥与配置管理 Kubernetes 允许您存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。 Kubernetes 组件 初学者首先要了解Kubernetes的基本概念,包括master、node、pod等。 Master Master是Kubernetes集群的大脑,运行着的守护进程服务包括kube-apiserver、kube-scheduler、kube-controller-manager、etcd和Pod网络等。 kube-apiserver 主节点上负责提供 Kubernetes API 服务的组件;它是 Kubernetes 控制面的前端。 kube-apiserver 在设计上考虑了水平扩缩的需要。 换言之,通过部署多个实例可以实现扩缩。 etcd etcd 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。 您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。 kube-scheduler 主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。 调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。 kube-controller-manager 在主节点上运行控制器的组件。 从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。 这些控制器包括: 节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应。 副本控制器(Replication Controller): 负责为系统中的每个副本控制器对象维护正确数量的 Pod。 端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)。 服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌. 云控制器管理器-(cloud-controller-manager) cloud-controller-manager 运行与基础云提供商交互的控制器 cloud-controller-manager 仅运行云提供商特定的控制器循环。您必须在 kube-controller-manager 中禁用这些控制器循环,您可以通过在启动 kube-controller-manager 时将 --cloud-provider 参数设置为 external 来禁用控制器循环。 cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中,核心的 Kubernetes 代码依赖于特定云提供商的代码来实现功能。在将来的版本中,云供应商专有的代码应由云供应商自己维护,并与运行 Kubernetes 的云控制器管理器相关联。 以下控制器具有云提供商依赖性: 节点控制器(Node Controller): 用于检查云提供商以确定节点是否在云中停止响应后被删除 路由控制器(Route Controller): 用于在底层云基础架构中设置路由 服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器 数据卷控制器(Volume Controller): 用于创建、附加和装载卷、并与云提供商进行交互以编排卷 Node 节点组件在每个节点上运行,维护运行 Pod 并提供 Kubernetes 运行环境。 kubelet 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。 kubelet 接收一组通过各类机制提供给它的 PodSpecs,确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。 kube-proxy kube-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。 kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。 如果有 kube-proxy 可用,它将使用操作系统数据包过滤层。否则,kube-proxy 会转发流量本身。 容器运行环境(Container Runtime) 容器运行环境是负责运行容器的软件。 Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。 Pod 在Kubernetes中,最小的管理元素不是一个个独立的容器,而是Pod。Pod是管理,创建,计划的最小单元. 一个Pod相当于一个共享context的配置组,在同一个context下,应用可能还会有独立的cgroup隔离机制,一个Pod是一个容器环境下的“逻辑主机”,它可能包含一个或者多个紧密相连的应用,这些应用可能是在同一个物理主机或虚拟机上。 Pod 的context可以理解成多个linux命名空间的联合 PID 命名空间(同一个Pod中应用可以看到其它进程) 网络 命名空间(同一个Pod的中的应用对相同的IP地址和端口有权限) IPC 命名空间(同一个Pod中的应用可以通过VPC或者POSIX进行通信) UTS 命名空间(同一个Pod中的应用共享一个主机名称) 同一个Pod中的应用可以共享磁盘,磁盘是Pod级的,应用可以通过文件系统调用。 由于docker的架构,一个Pod是由多个相关的并且共享磁盘的容器组成,Pid的命名空间共享还没有应用到Docker中 和相互独立的容器一样,Pod是一种相对短暂的存在,而不是持久存在的,正如我们在Pod的生命周期中提到的,Pod被安排到结点上,并且保持在这个节点上直到被终止(根据重启的设定)或者被删除,当一个节点死掉之后,上面的所有Pod均会被删除。特殊的Pod永远不会被转移到的其他的节点,作为替代,他们必须被replace. 三 通过kubeadm方式创建一个kubernetes 对kubernetes的概念和组件有所了解以后,就可以通过kubeadm的方式创建一个kubernetes集群。 安装前准备工作 创建虚拟机 创建至少2台虚拟机,可以在本地或者公有云。 下载部署软件 需要下载的软件包括calico、demo-images、docker-ce、kube、kube-images、kubectl、metrics-server 安装部署 具体安装过程参考官网文档: https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm/ 四 安装后的练习 安装后详读官方文档,做下面这些组件的练习操作,要达到非常熟练的程度。 Node Namespace Pod Deployment DaemonSet Service Job Static Pod ConfigMap Secrets Volume Init-containers Affinity and Anti-Affinity Monitor and logs Taints and Tolerations Cordon and Drain Backing up etcd 这些内容都非常熟练以后,基本就达到了入门的水平。

红亮 2020-03-02 11:09:17 0 浏览量 回答数 0

回答

浅谈Flutter框架原理及其生态圈 Flutter的锋芒 跨平台高性能的渲染引擎逐渐成为移动端、大前端领域的一个热点,作为其中的明星框架Flutter,经过近几年来的迅速发展,由极大的可能成为下一代跨端终端解决方案。自从2017 年 5 月,谷歌公司发布的了 Alpha 版本的 Flutter; 2018 年底 Flutter Live 发布的 1.0 版本;2019年7月发布1.5版本,截止今日(2020年2月)已经发布了v1.14.6 Beta版本。 在Flutter诞生之前,已经有许多跨平台UI框架的方案如Cordova、ReactNative、weex、uni-app、Hippy等,常见的需要处理兼容的终端平台也包括android、ios、web、Iot等,但是在大前端的浪潮下,对于企业和开发者来说开发效率和使用体验都十分重要,传统的做法莫过于分不同的团队开发不同的终端项目,如果还要继续向其他平台,拓展的话,我们需要付出的成本和时间将成倍增长。正因为如此,在这样的背景下,Flutter等跨端框架的兴起,从本质上讲,帮助开发者增加业务代码的复用率,减少因为要适配多个平台带来的工作量,从而降低开发成本、提高开发效率。 纵观已有的跨端方案,可以分为三类:Web 容器、泛 Web 容器、自绘引擎框架。 基于web容器即基于浏览器的跨平台也做得越来越好,自然管线也越来越短,与native的一些技术手段来实现性能上的相互补充。比如Egret、Cocos、Laya这些游戏引擎,它们在跨平台方面的做法多以Typescript编写,在iOS和安卓平台的各种浏览器中轻松的运行HTML5游戏,并在不同平台浏览器里提供近乎一致的用户体验,比如Egret还会提供高效的 JS-C Binding 编译机制,以满足游戏编译为原生格式的需求,不过大多数HTML游戏引擎也属于web容器这个范畴内。web容器框架也有一个明显的致命(在对体验&性能有较高要求的情况下)的缺点,那就是WebView的渲染效率和JavaScript执行性能太差。再加上Android各个系统版本和设备厂商的定制,很难保证所在所有设备上都能提供一致的体验。 泛 Web 容器框架比如ReactNative和Weex,即上层通过面向前端友好的UI,下层通过native的渲染形式,虽然同样使用类HTML+JS的UI构建逻辑,但是最终会生成对应的自定义原生控件,以充分利用原生控件相对于WebView的较高的绘制效率,同时H5与native相互补充来达到更好的用户体验,这也是一种很好的解决方案。缺陷也很明显,随着系统版本变化和API的变化,开发者可能也需要处理不同平台的差异,甚至有些特性只能在部分平台上实现,这样框架的跨平台特性就会大打折扣。 自绘引擎框架这里专指Flutter框架,从底层就承担跨端的任务和渲染方式,从目前来看,从技术的实现和方案的成熟度、产品的性能方面比较,Flutter有很大可能成为下一代主流跨平台框架。 Flutter与其他跨端框架的不同点之一就是自带渲染引擎,Flutter渲染引擎依靠跨平台的Skia图形库来实现,Skia引擎会将使用Dart语言构建的抽象的视图结构数据加工成GPU数据,交由 OpenGL 最终提供给 GPU 渲染,至此完成渲染闭环,因此可以在最大程度上保证一款应用在不同平台、不同设备上的体验一致性。 而开发语言选用的是同时支持 JIT和 AOT的 Dart语言,Dart本身提供了三种运行方式,应对web环境,用Dart2js编译成JavaScript代码,运行在常规浏览器中;使用DartVM直接在命令行中运行Dart代码;AOT方式编译成机器码,例如Flutter App框架。而且Dart 避免了抢占式调度和共享内存,可以在没有锁的情况下进行对象分配和垃圾回收,在性能方面表现相当不错,不仅保证了开发效率,代码性能和用户体验也更卓越。因此,Flutter在各类跨平台移动开发方案中脱颖而出。同时在去年2019的Google IO大会上,备受关注的Fuchsia系统虽然并没有发布,但是宣布了 Flutter除了支持开发 Android 和 iOS 程序之外,现在还支持开发Web程序了,在 I/O 大会上,谷歌发布了 Web 版 Flutter 的首个技术预览版,宣布 Flutter 将为包括 Google Home Hub 在内的 Google Smart Display 平台提供技术支持,并迈出利用 Chrome 操作系统支持桌面级应用的第一步。 很多JS开发者会思考Google Flutter团队至于为啥选择Dart而不是JS,其实Google 公司给出的原因很简单也很直接:Dart 语言开发组就在隔壁,对于 Flutter 需要的一些语言新特性,能够快速在语法层面落地实现;而如果选择了 JavaScript,就必须经过各种委员会(TC39等)和浏览器提供商漫长的决议。 Flutter绘制原理 在计算机系统中,图像的显示需要 CPU、GPU 和显示器一起配合完成:CPU 负责图像数据计算,GPU 负责图像数据渲染,而显示器则负责最终图像显示。 CPU 把计算好的、需要显示的内容交给 GPU,由 GPU 完成渲染后放入帧缓冲区,随后视频控制器根据垂直同步信号(VSync)以每秒 60 次的速度,从帧缓冲区读取帧数据交由显示器完成图像显示。 操作系统在呈现图像时遵循了这种机制,而 Flutter 作为跨平台开发框架也采用了这种底层方案。下面有一张更为详尽的示意图来解释 Flutter 的绘制原理。可以看到,Flutter 关注如何尽可能快地在两个硬件时钟的 VSync 信号之间计算并合成视图数据,然后通过 Skia 交给 GPU 渲染:UI 线程使用 Dart 来构建视图结构数据,这些数据会在 GPU 线程进行图层合成,随后交给 Skia 引擎加工成 GPU 数据,而这些数据会通过 OpenGL 最终提供给 GPU 渲染。 Skia原理 Skia 是一款用由C++ 开发的2D 图像绘制引擎。在2005 年被 Google 公司收购后被广泛应用在 Android和其他等核心产品上,Skia 目前是Android 官方的图像渲染引擎,因此 Flutter Android SDK 无需内嵌 Skia 引擎就可以获得天然的 Skia 支持;而对于 iOS 平台来说,由于 Skia 是跨平台的,因此它作为 Flutter iOS 渲染引擎被嵌入到 Flutter 的 iOS SDK 中,替代了 iOS 闭源的 Core Graphics/Core Animation/Core Text,这也正是 Flutter iOS SDK 打包的 App 包体积比 Android 要大一些的原因。 底层渲染能力统一了,上层开发接口和功能体验也就随即统一了,开发者再也不用操心平台相关的渲染特性了。也就是说,Skia 保证了同一套代码调用在 Android 和 iOS 平台上的渲染效果是完全一致的。 Flutter架构 Framework底层是Flutter引擎,引擎主要负责图形绘制(Skia)、文字排版(libtxt)和提供Dart运行时,引擎全部使用C++实现,Framework层使我们可以用Dart语言调用引擎的强大能力。Flutter 架构采用分层设计,从下到上分为三层,依次为:Embedder、Engine、Framework。 Embedder 是操作系统适配层,实现了渲染 Surface 设置,线程设置,以及平台插件等平台相关特性的适配。从这里我们可以看到,Flutter 平台相关特性并不多,这就使得从框架层面保持跨端一致性的成本相对较低。 Engine 层主要包含 Skia、Dart 和 Text,实现了 Flutter 的渲染引擎、文字排版、事件处理和 Dart 运行时等功能。Skia 和 Text 为上层接口提供了调用底层渲染和排版的能力,Dart 则为 Flutter 提供了运行时调用 Dart 和渲染引擎的能力。而 Engine 层的作用,则是将它们组合起来,从它们生成的数据中实现视图渲染。 Framework 层则是一个用 Dart 实现的 UI SDK,包含了动画、图形绘制和手势识别等功能。为了在绘制控件等固定样式的图形时提供更直观、更方便的接口,Flutter 还基于这些基础能力,根据 Material 和 Cupertino 两种视觉设计风格封装了一套 UI 组件库,开发者可以直接使用这些组件库。 Flutter运行流程 页面中的各界面元素(Widget)以树的形式组织,即控件树。Flutter 通过控件树中的每个控件创建不同类型的渲染对象,组成渲染对象树。在Flutter界面渲染过程分为三个阶段:布局、绘制、合成,布局和绘制在Flutter框架中完成,合成则交由引擎负责。 Flutter 采用深度优先机制遍历渲染对象树,决定渲染对象树中各渲染对象在屏幕上的位置和尺寸。在布局过程中,渲染对象树中的每个渲染对象都会接收父对象的布局约束参数,决定自己的大小,然后父对象按照控件逻辑决定各个子对象的位置,最终完成布局过程。这里只需要注意一点,无论布局还是绘制,都是父子间的遍历关系:父Widget的布局需要依赖子Widget的布局结果;而绘制则反过来(子Widget需要盖在父Widget上),布局是后续遍历,绘制是前序遍历,他们都是深度优先遍历。 Flutter生命周期 可以看到,Flutter中State 的生命周期可以分为 3 个阶段:创建(插入视图树)、更新(在视图树中存在)、销毁(从视图树中移除)。接下来,我们一起看看每一个阶段的具体流程。 第一步创建 State 初始化时会依次执行 :构造方法 -> initState -> didChangeDependencies -> build,随后完成页面渲染。构造方法是 State 生命周期的起点,Flutter 会通过调用StatefulWidget.createState() 来创建一个 State。我们可以通过构造方法,来接收父 Widget 传递的初始化 UI 配置数据。这些配置数据,决定了 Widget 最初的呈现效果。 initState,会在 State 对象被插入视图树的时候调用。这个函数在 State 的生命周期中只会被调用一次,所以我们可以在这里做一些初始化工作,比如为状态变量设定默认值。 didChangeDependencies 则用来专门处理 State 对象依赖关系变化,会在 initState() 调用结束后,被 Flutter 调用。 build,作用是构建视图。经过以上步骤,Framework 认为 State 已经准备好了,于是调用 build。我们需要在这个函数中,根据父 Widget 传递过来的初始化配置数据,以及 State 的当前状态,创建一个 Widget 然后返回。 第二步更新 Widget 的状态更新,主要由个方法触发:setState、didchangeDependencies、didUpdateWidget。 setState:我们最熟悉的方法之一。当状态数据发生变化时,我们总是通过调用这个方法告诉 Flutter:“我这儿的数据变啦,请使用更新后的数据重建 UI!” didChangeDependencies:State 对象的依赖关系发生变化后,Flutter 会回调这个方法,随后触发组件构建。哪些情况下 State 对象的依赖关系会发生变化呢?典型的场景是,系统语言 Locale 或应用主题改变时,系统会通知 State 执行 didChangeDependencies 回调方法。 didUpdateWidget:当 Widget 的配置发生变化时,比如,父 Widget 触发重建(即父 Widget 的状态发生变化时),热重载时,系统会调用这个函数。一旦这三个方法被调用,Flutter 随后就会销毁老 Widget,并调用 build 方法重建 Widget。 第三步销毁 比如组件被移除,或是页面销毁的时候,系统会调用 deactivate 和 dispose 这两个方法,来移除或销毁组件。 Flutter生态圈及其常用框架 一项技术一个框架是否流行,最直观的体现就是它的生态圈是否活跃,下面列举了一些Flutter开发中常用的库工具。 参考文献 1、[Flutter原理与实践](https://tech.meituan.com/2018/08/09/waimai-flutter-practice.html) 少杰 2、[Flutter框架技术概览](https://flutter.dev/docs/resources/technical-overview) 3、[Flutter中文官网](https://pub.dartlang.org/flutter/) 4、[Flutter插件仓库](https://pub.dev/flutter/packages)

罗思雨 2020-02-27 11:47:50 0 浏览量 回答数 0

问题

厉华:写一个开源容器引擎会是什么样的体验? 热:报错

kun坤 2020-06-10 10:01:12 3 浏览量 回答数 1

回答

服务器和操作系统 1、主板的两个芯片分别是什么芯片,具备什么作用? 北桥:离CPU近,负责CPU、内存、显卡之间的通信。 南桥:离CPU远,负责I/O总线之间的通信。 2、什么是域和域控制器? 将网络中的计算机逻辑上组织到一起,进行集中管理,这种集中管理的环境称为域。 在域中,至少有一台域控制器,域控制器中保存着整个域的用户账号和安全数据,安装了活动目录的一台计算机为域控制器,域管理员可以控制每个域用户的行为。 3、现在有300台虚拟机在云上,你如何进行管理? 1)设定堡垒机,使用统一账号登录,便于安全与登录的考量。 2)使用ansiable、puppet进行系统的统一调度与配置的统一管理。 3)建立简单的服务器的系统、配置、应用的cmdb信息管理。便于查阅每台服务器上的各种信息记录。 4、简述raid0 raid1 raid5 三种工作模式的工作原理及特点 磁盘冗余阵列(Redundant Arrays of Independent Disks,RAID),把硬盘整合成一个大磁盘,在大磁盘上再分区,存放数据、多块盘放在一起可以有冗余(备份)。 RAID整合方式有很多,常用的:0 1 5 10 RAID 0:可以是一块盘和N个盘组合 优点:读写快,是RAID中最好的 缺点:没有冗余,一块坏了数据就全没有了 RAID 1:只能2块盘,盘的大小可以不一样,以小的为准 10G+10G只有10G,另一个做备份。它有100%的冗余,缺点:浪费资源,成本高 RAID 5 :3块盘,容量计算10*(n-1),损失一块盘 特点:读写性能一般,读还好一点,写不好 总结: 冗余从好到坏:RAID1 RAID10 RAID 5 RAID0 性能从好到坏:RAID0 RAID10 RAID5 RAID1 成本从低到高:RAID0 RAID5 RAID1 RAID10 5、linux系统里,buffer和cache如何区分? buffer和cache都是内存中的一块区域,当CPU需要写数据到磁盘时,由于磁盘速度比较慢,所以CPU先把数据存进buffer,然后CPU去执行其他任务,buffer中的数据会定期写入磁盘;当CPU需要从磁盘读入数据时,由于磁盘速度比较慢,可以把即将用到的数据提前存入cache,CPU直接从Cache中拿数据要快的多。 6、主机监控如何实现? 数据中心可以用zabbix(也可以是nagios或其他)监控方案,zabbix图形界面丰富,也自带很多监控模板,特别是多个分区、多个网卡等自动发现并进行监控做得非常不错,不过需要在每台客户机(被监控端)安装zabbix agent。 如果在公有云上,可以使用云监控来监控主机的运行。 网络 7、主机与主机之间通讯的三要素有什么? IP地址、子网掩码、IP路由 8、TCP和UDP都可以实现客户端/服务端通信,这两个协议有何区别? TCP协议面向连接、可靠性高、适合传输大量数据;但是需要三次握手、数据补发等过程,耗时长、通信延迟大。 UDP协议面向非连接、可靠性低、适合传输少量数据;但是连接速度快、耗时短、延迟小。 9、简述TCP协议三次握手和四次分手以及数据传输过程 三次握手: (1)当主机A想同主机B建立连接,主机A会发送SYN给主机B,初始化序列号seq=x。主机A通过向主机B发送SYS报文段,实现从主机A到主机B的序列号同步,即确定seq中的x。 (2)主机B接收到报文后,同意与A建立连接,会发送SYN、ACK给主机A。初始化序列号seq=y,确认序号ack=x+1。主机B向主机A发送SYN报文的目的是实现从主机B到主机A的序列号同步,即确定seq中的y。 (3)主机A接收到主机B发送过来的报文后,会发送ACK给主机B,确认序号ack=y+1,建立连接完成,传输数据。 四次分手: (1)当主机A的应用程序通知TCP数据已经发送完毕时,TCP向主机B发送一个带有FIN附加标记的报文段,初始化序号seq=x。 (2)主机B收到这个FIN报文段,并不立即用FIN报文段回复主机A,而是想主机A发送一个确认序号ack=x+1,同时通知自己的应用程序,对方要求关闭连接(先发ack是防止主机A重复发送FIN报文)。 (3)主机B发送完ack确认报文后,主机B 的应用程序通知TCP我要关闭连接,TCP接到通知后会向主机A发送一个带有FIN附加标记的报文段,初始化序号seq=x,ack=x+1。 (4)主机A收到这个FIN报文段,向主机B发送一个ack确认报文,ack=y+1,表示连接彻底释放。 10、SNAT和DNAT的区别 SNAT:内部地址要访问公网上的服务时(如web访问),内部地址会主动发起连接,由路由器或者防火墙上的网关对内部地址做个地址转换,将内部地址的私有IP转换为公网的公有IP,网关的这个地址转换称为SNAT,主要用于内部共享IP访问外部。 DNAT:当内部需要提供对外服务时(如对外发布web网站),外部地址发起主动连接,由路由器或者防火墙上的网关接收这个连接,然后将连接转换到内部,此过程是由带有公网IP的网关替代内部服务来接收外部的连接,然后在内部做地址转换,此转换称为DNAT,主要用于内部服务对外发布。 数据库 11、叙述数据的强一致性和最终一致性 强一致性:在任何时刻所有的用户或者进程查询到的都是最近一次成功更新的数据。强一致性是程度最高一致性要求,也是最难实现的。关系型数据库更新操作就是这个案例。 最终一致性:和强一致性相对,在某一时刻用户或者进程查询到的数据可能都不同,但是最终成功更新的数据都会被所有用户或者进程查询到。当前主流的nosql数据库都是采用这种一致性策略。 12、MySQL的主从复制过程是同步的还是异步的? 主从复制的过程是异步的复制过程,主库完成写操作并计入binlog日志中,从库再通过请求主库的binlog日志写入relay中继日志中,最后再执行中继日志的sql语句。 **13、MySQL主从复制的优点 ** 如果主服务器出现问题,可以快速切换到从服务器提供的服务; 可以在从服务器上执行查询操作,降低主服务器的访问压力; 可以在从服务器上执行备份,以避免备份期间影响主服务器的服务。 14、redis有哪些数据类型? (一)String 最常规的set/get操作,value可以是String也可以是数字。一般做一些复杂的计数功能的缓存。 (二)hash 这里value存放的是结构化的对象,比较方便的就是操作其中的某个字段。做单点登录的时候,就是用这种数据结构存储用户信息,以cookieId作为key,设置30分钟为缓存过期时间,能很好的模拟出类似session的效果。 (三)list 使用List的数据结构,可以做简单的消息队列的功能。另外还有一个就是,可以利用lrange命令,做基于redis的分页功能,性能极佳,用户体验好。 (四)set 因为set堆放的是一堆不重复值的集合。所以可以做全局去重的功能。为什么不用JVM自带的Set进行去重?因为我们的系统一般都是集群部署,使用JVM自带的Set,比较麻烦,难道为了一个做一个全局去重,再起一个公共服务,太麻烦了。 另外,就是利用交集、并集、差集等操作,可以计算共同喜好,全部的喜好,自己独有的喜好等功能。 (五)Zset Zset多了一个权重参数score,集合中的元素能够按score进行排列。可以做排行榜应用,取TOP N操作。另外,sorted set可以用来做延时任务。最后一个应用就是可以做范围查找。 15、叙述分布式数据库及其使用场景? 分布式数据库应该是数据访问对应用透明,每个分片默认采用主备架构,提供灾备、恢复、监控、不停机扩容等整套解决方案,适用于TB或PB级的海量数据场景。 应用 16、Apache、Nginx、Lighttpd都有哪些特点? Apache特点:1)几乎可以运行在所有的计算机平台上;2)支持最新的http/1.1协议;3)简单而且强有力的基于文件的配置(httpd.conf);4)支持通用网关接口(cgi);5)支持虚拟主机;6)支持http认证,7)集成perl;8)集成的代理服务器;9)可以通过web浏览器监视服务器的状态,可以自定义日志;10)支持服务器端包含命令(ssi);11)支持安全socket层(ssl);12)具有用户绘画过程的跟踪能力;13)支持fastcgi;14)支持java servlets Nginx特点:nginx是一个高性能的HTTP和反向代理服务器,同时也是一个IMAP/POP3/SMTP代理服务器,处理静态文件,索引文件以及自动索引,无缓存的反向代理加速,简单的负载均衡和容错,具有很高的稳定性,支持热部署。 Lighttpd特点:是一个具有非常低的内存开销,CPU占用率低,效能好,以及丰富的模块,Lighttpd是众多opensource轻量级的webserver中较为优秀的一个,支持fastcgi,cgi,auth,输出压缩,url重写,alias等重要功能。 17、LVS、NGINX、HAPROXY的优缺点? LVS优点:具有很好的可伸缩性、可靠性、可管理性。抗负载能力强、对内存和CPU资源消耗比较低。工作在四层上,仅作分发,所以它几乎可以对所有的应用做负载均衡,且没有流量的产生,不会受到大流量的影响。 LVS缺点:软件不支持正则表达式处理,不能做动静分离,如果web应用比较庞大,LVS/DR+KEEPALIVED实施和管理比较复杂。相对而言,nginx和haproxy就简单得多。 nginx优点:工作在七层之上,可以针对http应用做一些分流的策略。比如针对域名、目录结构。它的正则规则比haproxy更为强大和灵活。对网络稳定性依赖非常小。理论上能PING就能进行负载均衡。配置和测试简单,可以承担高负载压力且稳定。nginx可以通过端口检测到服务器内部的故障。比如根据服务器处理网页返回的状态码、超时等。并且可以将返回错误的请求重新发送给另一个节点,同时nginx不仅仅是负载均衡器/反向代理软件。同时也是功能强大的web服务器,可以作为中层反向代理、静态网页和图片服务器使用。 nginx缺点:不支持URL检测,仅支持HTTP和EMAIL,对session的保持,cookie的引导能力相对欠缺。 Haproxy优点:支持虚拟主机、session的保持、cookie的引导;同时支持通过获取指定的url来检测后端服务器的状态。支持TCP协议的负载均衡;单纯从效率上讲比nginx更出色,且负载策略非常多。 aproxy缺点:扩展性能差;添加新功能很费劲,对不断扩展的新业务很难对付。 18、什么是中间件?什么是jdk? 中间件介绍: 中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源 中间件位于客户机/ 服务器的操作系统之上,管理计算机资源和网络通讯 是连接两个独立应用程序或独立系统的软件。相连接的系统,即使它们具有不同的接口 但通过中间件相互之间仍能交换信息。执行中间件的一个关键途径是信息传递 通过中间件,应用程序可以工作于多平台或OS环境。 jdk:jdk是Java的开发工具包 它是一种用于构建在 Java 平台上发布的应用程序、applet 和组件的开发环境 19、日志收集、日志检索、日志展示的常用工具有哪些? ELK或EFK。 Logstash:数据收集处理引擎。支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等操作,然后存储以供后续使用。 Kibana:可视化化平台。它能够搜索、展示存储在 Elasticsearch 中索引数据。使用它可以很方便的用图表、表格、地图展示和分析数据。 Elasticsearch:分布式搜索引擎。具有高可伸缩、高可靠、易管理等特点。可以用于全文检索、结构化检索和分析,并能将这三者结合起来。Elasticsearch 基于 Lucene 开发,现在使用最广的开源搜索引擎之一,Wikipedia 、StackOverflow、Github 等都基于它来构建自己的搜索引擎。 Filebeat:轻量级数据收集引擎。基于原先 Logstash-fowarder 的源码改造出来。换句话说:Filebeat就是新版的 Logstash-fowarder,逐渐取代其位置。 20、什么是蓝绿发布和灰度发布? 蓝绿:旧版本-新版本 灰度:新旧版本各占一定比例,比例可自定义 两种发布都通过devops流水线实现

剑曼红尘 2020-03-23 15:51:44 0 浏览量 回答数 0

回答

燃财经(ID:rancaijing)原创 作者 | 唐亚华 编辑 | 魏佳 春节临近,一年一度人口大迁移又要来临。 虽然12306近日已经宣称屏蔽了部分抢票软件,并推出官方候补功能,但市面上提供抢票服务的仍然有智行火车票、 高铁管家、携程、美团、飞猪、同程艺龙等60多个软件。 不过,多名用户反馈称“这届抢票软件不行”,即便用了加速包、买了VIP会员还是抢不到票。技术专家告诉燃财经,从原理上来说,抢票软件只是将用户手动购买车票的链路照搬,用机器来操作,利用企业带宽和机器速度来当“代购”。购买了加速包或VIP的不同之处在于,刷新的频率可能会从30秒一次变成10秒一次或5秒一次,或者多个服务器同时抢票。但是,能不能抢到票仍然是概率问题。 即便如此,仍有众多抢票软件在加速包、VIP会员、优先出票权、安心抢等名目上“动脑筋”,燃财经测试发现,如果要一步一步升级到“抢票顶配”,在携程上需要花费138元,在美团上需要花费80元。这也让不少人诟病抢票软件有捆绑、诱导消费之嫌。 事实上,抢票难的根源在于春节这样短期的大规模迁徙带来的巨大需求缺口难以满足,消费者能做的就是谨慎选择、找准时机、注意捡漏及多种方式搭配。在巨大的需求之下,抢票软件和其商机也将长期存在,但套路不是长久之计,真正为用户提供价值才能让人继续买单。 抢票是一门玄学 自2019年12月12日进入春运以来,“我在XX抢票,快来帮我加速。皮皮虾,我们抢”、“为我回家助把力”、“你不点我不点,小X回家有危险”的文案又开始出现在各大微信群,为抢票助力和“砍一刀”都成了大家考验人缘的方式。 尽管不久前12306对外表示已经屏蔽了多个抢票软件,但燃财经了解到,智行火车票、高铁管家、携程、美团、飞猪、去哪儿、同城艺龙等60多家平台仍然推出了抢票功能。 不过,这一次,用户的反馈不同以往,结合论坛中网友的反馈和燃财经的采访情况,大家普遍反映“这届抢票软件不行”,即便用了加速包、买了VIP会员还是抢不到票,这也引发了大家对于春运抢票加速包是“真有用”还是“智商税”的讨论。 用户小黎告诉燃财经,他在智行火车票上预约了春节回家的火车票,放票时间一到,抢票软件一直显示“抢票中”但并没有成功。心急之下,他自己登上12306官网,发现显示还有余票,很顺利就买上了。“我怀疑不买加速包,抢票软件是不是根本就不给抢。” 另一位用户张宇在智行火车票、携程、美团都提交了抢票订单并购买了40元极速抢票服务,连续抢了三天仍然没有抢到北京到日照的车票。她表示,前几年用抢票软件都能挺顺利抢到,这一次有点失望。 “这两天我用飞猪抢票,加了30元手续费。从放票开始,我就一直守在手机、电脑前。结果飞猪软件里一直显示无票。我又去贴吧看,发现有人在12306官网买到票了,但飞猪还是显示无票。花了30元的VIP手续费,自始至终没看见显示有票,还不如免费抢票软件。”某网友感叹。 抢票软件套路多 尽管抢票软件的效果不能保证,但套路还不少。 燃财经体验了智行火车票、携程、美团、飞猪等平台的抢票后发现,各大平台的抢票方式大同小异,总体感受是不用加速包、不买VIP基本抢不到票,但买了也不承诺能抢到。因为各平台的规则不透明,没有一家承诺100%抢到票,只会提供预估成功率,而这个成功率到底是70%还是98%,在用户端感知不到差异。 总结来看,抢票软件大致有以下几种套路。 首先是用不明显的字体颜色诱使用户购买“加速包”或VIP会员。如下图携程和美团的购票页面上,要购买加速包的“极速购票”用红色字体,不用加钱的“低速抢票”则是不明显的浅灰色字体,不仔细看的用户有可能不小心勾选付费极速抢票的选项。燃财经在测试时,就差点没找到免费的抢票选项。 另外,在文案上制造焦虑也是常见的方式。“低速抢票难度很高,很可能失败”、“低速度抢票成功率52.2%,极速抢票成功率68.86”、“52%的加速用户选择光速抢票”等提示,很容易给用户制造出一种不用加速包、不花钱就抢不到票的焦虑。 第三,平台会不断提醒用户升级加速包,用上了抢票软件就开始一步一步走入它们的套路中。 抢票软件的抢票速度分为低速、快速、高速、极速、光速、VIP,如果你先选择了低速的免费抢票,系统会显示“邀请好友来助力,最高升至光速抢票”,此时,邀请好友点击助力、看广告就是平台的用意。 而当票没抢到时,页面上会有多个提示你升级的选项,燃财经尝试在各平台上都选择了40元极速抢票,本以为高枕无忧了,没想到这才是个开始。如携程还设置了“优先出票特权:发现余票将优先为你出票,10元/人”、“开通超级会员,免费升级VIP抢票,88元/年”,燃财经计算发现,如果直接开通超级会员需要88元,而一步一步升级到抢票顶配,预计需要加138元。 在美团上选择了40元极速抢票后,系统提醒还差10分加速包升至光速抢票,成功率59%,10元/人,VIP抢票成功率61%,30元/人,想升级到顶配需要80元。智行火车票显示从低速到中速、快速、高速、极速、VIP分别需要10元、20元、30元、40元、50元。 另外,去哪儿旅行上还有“安心抢”、“请朋友帮我挂机”、“购买抢票年卡,72元享3次VIP抢票”等选项,而邀请朋友助力时,软件会获取用户的位置、手机号等信息。 最后,尽管有一些抢票软件承诺抢不到票全额退款,但抢票软件会提示用户勾选更多车次、更多时间、跨站抢票以提升抢票成功概率,最终用户买到的并不是“最优选”,但也无法退费。 以上这些套路也是用户吐槽投诉的重灾区。黑猫投诉上有152条关于抢票软件的投诉,例如“智行火车票二次收费”、“同城艺龙购票98%的成功率却抢不到票”、“高铁管家强制套餐消费”等,多是抢票软件诱导消费、退费难的问题。 众多抢票软件的存在,事实上提高了所有人的抢票门槛。这些五花八门的加速选项,增加消费者的筛选成本,抢到了是运气,抢不到只好自认倒霉。 另外,不少APP存在个人信息泄露的风险。抢票软件作为一个工具类插件,技术开发上的门槛较低,用户输入12306的网站用户名、密码等个人信息被传到平台服务器后,如果安全保护性太低,个人信息很容易被泄露。 抢票软件等于外挂 能不能抢到是概率 抢票软件的加速包真的有效果吗,背后的技术原理又是什么呢? 径点科技首席架构师张英辉告诉燃财经:“我们去12306买票的时候要输入信息、查询、购买,所有的抢票软件都是基于同一种原理,将这些手动操作的步骤用程序来实现,然后不停重试。在用户手速和刷票频率的局限下,第三方抢票平台利用机器刷票、全自动化处理有其优势。” 他还提到,购买了加速包或VIP的不同之处在于,刷新的频率可能会从30秒一次变成10秒一次或5秒一次,或者多个服务器同时抢票。因为消费者大多使用的是普通4G以及20M光纤宽带,跟平台使用的企业级宽带的网速自然是不能相比的,在这个拼速度的模式里,抢票软件集合了企业宽带和机器速度的“代购”,就相当于打游戏的时候加了外挂。 整体来看,刷得越勤,用的服务器越多,抢中票的概率越大,但在实际操作中能不能刷中,可能要看那一秒的时间窗口。“因为市面上有60多个刷票软件,某一趟车从一个站到另外一个站的余票情况随时都在变,这种情况下,谁能刷中不一定,取决于刚好出票这一秒哪个软件在刷。”张英辉强调,抢票软件并不能增加车票,12306系统上没票的时候,再多的加速包都没用。 这个过程中还有12306和抢票软件之间的攻防博弈战。 张英辉指出,从技术上来说,12306后台能检测出刷票软件,如果刷票带来的负担超过网站的负荷,后台通常会限制这样的账号,同一IP地址刷票过于频繁或同一购买请求提交过于频繁,都有可能被拖入慢速或被屏蔽掉。但至于具体是什么限流规则,是由12306来制定、调整和实施。 当然,被屏蔽后的刷票软件可能会通过更换IP地址、使用多台服务器轮流操作等方式规避检测。刷票软件也在持续研究怎样绕过官方规则,双方在不停地博弈。所以用户用抢票软件没买到票,可能是因为没刷到,也可能是刷票软件被屏蔽了。 中国铁道科学研究院12306技术部主任单杏花在2019年接受媒体采访时表示,12306已经对第三方抢票软件的相关特征进行识别并实施了流量拦截,即使用户花钱购买了第三方抢票平台的加速服务,购票的成功率也会大打折扣。另外,12306已经推出了“官方抢票”的候补功能,如果遇到有旅客退签返回的车票,或者是铁路方面根据列车能力情况加挂而增加的车票,就可以优先配给已经排队等候的人。 “刷票软件本身的技术难度不大,市面上甚至有很多免费刷票程序或源代码,稍微懂点的人自己都能安装刷票,但要想把刷票功能做得强大很难。要支持大量用户的需求,又要避开12306的监管,可能就需要投入更多的服务器、人力。说白了,给一个人低速刷票很容易,给100万人快速刷票就会变得复杂。”另一位技术人士李元表示。 从理论上说,平台需要投入设备、人力,完成抢票工作后,收取额外的资源占用费是合理的。张英辉认为,问题在于抢票软件在提高概率的同时也提高了买票者的心理预期,一些花了钱没有达到目的的人就会有负面反馈。用户期望交了钱就买到票,但这明显是个概率模式,必然会出现有的刷得到、有的没刷到的情况。 抢票难题和抢票软件将长期存在 经常有人说,微信几亿人同时在用,双11的时候淘宝那么大的流量都能正常运转,12306为啥连个买票软件都做不好? 张英辉解释,12306的业务逻辑要远远比微信和淘宝复杂得多,比如一辆列车经过,中间是十几个站,不停地有人下有人上,还有人换乘,之间有几百种可能性,系统库存随时在变。如果微信有一条消息没发出去或者发了两次是小事,但一张票如果卖给了两个人,这是重大失误。 另外,12306的库存变化又受到网站、APP、售票厅、自动售票机等多方的实时变动影响,用户需求又有时间、车次、地点的无数种排列组合情况,且整个路程在短时间内就要完成,还要验证用户身份以排除同一车次同一人的重复购买,市面上的众多抢票软件还增加了12306的数据压力,系统无论从技术的完整性和资源调度上都远远比微信和淘宝的业务复杂得多。 他还指出,12306最开始采购的应用可能能够支撑平时1亿人访问,但是到了春节期间,有几亿人同时访问,后台需要采购的设备也不是一时就能实现的,购买、部署、调试等整个周期环节就很长,但春节以后又没有那么大的流量了,硬件折旧损耗,人力维护成本都会浪费,所以12306如果只是为了春运和几个大的节假日去加技术和硬件,实际上也是不可行的。 说到底,铁路总运力是一定的,春运这个非常态的需求是极其巨大的,抢票软件并不能增加供给,也不会提高整体买到票的概率,抢票难的根本原因是供求关系不平衡。 加入阿里云钉钉群享福利:每周技术直播,定期群内有奖活动、大咖问答 阿里云开发者社区

茶什i 2020-01-08 11:53:49 0 浏览量 回答数 0

问题

程序员的3年之痒改变的不止薪水

小柒2012 2019-12-01 21:08:36 19089 浏览量 回答数 18

问题

SaaS模式云数据仓库MaxCompute 百问百答合集(持续更新20200921)

亢海鹏 2020-05-29 15:10:00 19050 浏览量 回答数 5

回答

前言 这期我想写很久了,但是因为时间的原因一直拖到了现在,我以为一两天就写完了,结果从构思到整理资料,再到写出来用了差不多一周的时间吧。 你们也知道丙丙一直都是创作鬼才来的,所以我肯定不会一本正经的写,我想了好几个切入点,最后决定用一个完整的电商系统作为切入点,带着大家看看,我们需要学些啥,我甚至还收集配套视频和资料,暖男石锤啊,这期是呕心沥血之作,不要白嫖了。 正文 在写这个文章之前,我花了点时间,自己臆想了一个电商系统,基本上算是麻雀虽小五脏俱全,我今天就用它开刀,一步步剖析,我会讲一下我们可能会接触的技术栈可能不全,但是够用,最后给个学习路线。 Tip:请多欣赏一会,每个点看一下,看看什么地方是你接触过的,什么技术栈是你不太熟悉的,我觉得还算是比较全的,有什么建议也可以留言给我。 不知道大家都看了一下没,现在我们就要庖丁解牛了,我从上到下依次分析。 前端 你可能会会好奇,你不是讲后端学习路线嘛,为啥还有前端的部分,我只能告诉你,傻瓜,肤浅。 我们可不能闭门造车,谁告诉你后端就不学点前端了? 前端现在很多也了解后端的技术栈的,你想我们去一个网站,最先接触的,最先看到的是啥? 没错就是前端,在大学你要是找不到专门的前端同学,去做系统肯定也要自己顶一下前端的,那我觉得最基本的技术栈得熟悉和了解吧,丙丙现在也是偶尔会开发一下我们的管理系统主要是VUE和React。 在这里我列举了我目前觉得比较简单和我们后端可以了解的技术栈,都是比较基础的。 作为一名后端了解部分前端知识还是很有必要的,在以后开发的时候,公司有前端那能帮助你前后端联调更顺畅,如果没前端你自己也能顶一下简单的页面。 HTML、CSS、JS、Ajax我觉得是必须掌握的点,看着简单其实深究或者去操作的话还是有很多东西的,其他作为扩展有兴趣可以了解,反正入门简单,只是精通很难很难。 在这一层不光有这些还有Http协议和Servlet,request、response、cookie、session这些也会伴随你整个技术生涯,理解他们对后面的你肯定有不少好处。 Tip:我这里最后删除了JSP相关的技术,我个人觉得没必要学了,很多公司除了老项目之外,新项目都不会使用那些技术了。 前端在我看来比后端难,技术迭代比较快,知识好像也没特定的体系,所以面试大厂的前端很多朋友都说难,不是技术多难,而是知识多且复杂,找不到一个完整的体系,相比之下后端明朗很多,我后面就开始讲后端了。 网关层: 互联网发展到现在,涌现了很多互联网公司,技术更新迭代了很多个版本,从早期的单机时代,到现在超大规模的互联网时代,几亿人参与的春运,几千亿成交规模的双十一,无数互联网前辈的造就了现在互联网的辉煌。 微服务,分布式,负载均衡等我们经常提到的这些名词都是这些技术在场景背后支撑。 单机顶不住,我们就多找点服务器,但是怎么将流量均匀的打到这些服务器上呢? 负载均衡,LVS 我们机器都是IP访问的,那怎么通过我们申请的域名去请求到服务器呢? DNS 大家刷的抖音,B站,快手等等视频服务商,是怎么保证同时为全国的用户提供快速的体验? CDN 我们这么多系统和服务,还有这么多中间件的调度怎么去管理调度等等? zk 这么多的服务器,怎么对外统一访问呢,就可能需要知道反向代理的服务器。 Nginx 这一层做了反向负载、服务路由、服务治理、流量管理、安全隔离、服务容错等等都做了,大家公司的内外网隔离也是这一层做的。 我之前还接触过一些比较有意思的项目,所有对外的接口都是加密的,几十个服务会经过网关解密,找到真的路由再去请求。 这一层的知识点其实也不少,你往后面学会发现分布式事务,分布式锁,还有很多中间件都离不开zk这一层,我们继续往下看。 服务层: 这一层有点东西了,算是整个框架的核心,如果你跟我帅丙一样以后都是从事后端开发的话,我们基本上整个技术生涯,大部分时间都在跟这一层的技术栈打交道了,各种琳琅满目的中间件,计算机基础知识,Linux操作,算法数据结构,架构框架,研发工具等等。 我想在看这个文章的各位,计算机基础肯定都是学过的吧,如果大学的时候没好好学,我觉得还是有必要再看看的。 为什么我们网页能保证安全可靠的传输,你可能会了解到HTTP,TCP协议,什么三次握手,四次挥手。 还有进程、线程、协程,什么内存屏障,指令乱序,分支预测,CPU亲和性等等,在之后的编程生涯,如果你能掌握这些东西,会让你在遇到很多问题的时候瞬间get到点,而不是像个无头苍蝇一样乱撞(然而丙丙还做得不够)。 了解这些计算机知识后,你就需要接触编程语言了,大学的C语言基础会让你学什么语言入门都会快点,我选择了面向对象的JAVA,但是也不知道为啥现在还没对象。 JAVA的基础也一样重要,面向对象(包括类、对象、方法、继承、封装、抽象、 多态、消息解析等),常见API,数据结构,集合框架,设计模式(包括创建型、结构型、行为型),多线程和并发,I/O流,Stream,网络编程你都需要了解。 代码会写了,你就要开始学习一些能帮助你把系统变得更加规范的框架,SSM可以会让你的开发更加便捷,结构层次更加分明。 写代码的时候你会发现你大学用的Eclipse在公司看不到了,你跟大家一样去用了IDEA,第一天这是什么玩意,一周后,真香,但是这玩意收费有点贵,那免费的VSCode真的就是不错的选择了。 代码写的时候你会接触代码的仓库管理工具maven、Gradle,提交代码的时候会去写项目版本管理工具Git。 代码提交之后,发布之后你会发现很多东西需要自己去服务器亲自排查,那Linux的知识点就可以在里面灵活运用了,查看进程,查看文件,各种Vim操作等等。 系统的优化很多地方没优化的空间了,你可能会尝试从算法,或者优化数据结构去优化,你看到了HashMap的源码,想去了解红黑树,然后在算法网上看到了二叉树搜索树和各种常见的算法问题,刷多了,你也能总结出精华所在,什么贪心,分治,动态规划等。 这么多个服务,你发现HTTP请求已经开始有点不满足你的需求了,你想开发更便捷,像访问本地服务一样访问远程服务,所以我们去了解了Dubbo,Spring cloud。 了解Dubbo的过程中,你发现了RPC的精华所在,所以你去接触到了高性能的NIO框架,Netty。 代码写好了,服务也能通信了,但是你发现你的代码链路好长,都耦合在一起了,所以你接触了消息队列,这种异步的处理方式,真香。 他还可以帮你在突发流量的时候用队列做缓冲,但是你发现分布式的情况,事务就不好管理了,你就了解到了分布式事务,什么两段式,三段式,TCC,XA,阿里云的全局事务服务GTS等等。 分布式事务的时候你会想去了解RocketMQ,因为他自带了分布式事务的解决方案,大数据的场景你又看到了Kafka。 我上面提到过zk,像Dubbo、Kafka等中间件都是用它做注册中心的,所以很多技术栈最后都组成了一个知识体系,你先了解了体系中的每一员,你才能把它们联系起来。 服务的交互都从进程内通信变成了远程通信,所以性能必然会受到一些影响。 此外由于很多不确定性的因素,例如网络拥塞、Server 端服务器宕机、挖掘机铲断机房光纤等等,需要许多额外的功能和措施才能保证微服务流畅稳定的工作。 **Spring Cloud **中就有 Hystrix 熔断器、Ribbon客户端负载均衡器、Eureka注册中心等等都是用来解决这些问题的微服务组件。 你感觉学习得差不多了,你发现各大论坛博客出现了一些前沿技术,比如容器化,你可能就会去了解容器化的知识,像**Docker,Kubernetes(K8s)**等。 微服务之所以能够快速发展,很重要的一个原因就是:容器化技术的发展和容器管理系统的成熟。 这一层的东西呢其实远远不止这些的,我不过多赘述,写多了像个劝退师一样,但是大家也不用慌,大部分的技术都是慢慢接触了,工作中慢慢去了解,去深入的。 好啦我们继续沿着图往下看,那再往下是啥呢? 数据层: 数据库可能是整个系统中最值钱的部分了,在我码文字的前一天,刚好发生了微盟程序员删库跑路的操作,删库跑路其实是我们在网上最常用的笑话,没想到还是照进了现实。 这里也提一点点吧,36小时的故障,其实在互联网公司应该是个笑话了吧,权限控制没做好类似rm -rf 、fdisk、drop等等这样的高危命令是可以实时拦截掉的,备份,全量备份,增量备份,延迟备份,异地容灾全部都考虑一下应该也不至于这样,一家上市公司还是有点点不应该。 数据库基本的事务隔离级别,索引,SQL,主被同步,读写分离等都可能是你学的时候要了解到的。 上面我们提到了安全,不要把鸡蛋放一个篮子的道理大家应该都知道,那分库的意义就很明显了,然后你会发现时间久了表的数据大了,就会想到去接触分表,什么TDDL、Sharding-JDBC、DRDS这些插件都会接触到。 你发现流量大的时候,或者热点数据打到数据库还是有点顶不住,压力太大了,那非关系型数据库就进场了,Redis当然是首选,但是MongoDB、memcache也有各自的应用场景。 Redis使用后,真香,真快,但是你会开始担心最开始提到的安全问题,这玩意快是因为在内存中操作,那断点了数据丢了怎么办?你就开始阅读官方文档,了解RDB,AOF这些持久化机制,线上用的时候还会遇到缓存雪崩击穿、穿透等等问题。 单机不满足你就用了,他的集群模式,用了集群可能也担心集群的健康状态,所以就得去了解哨兵,他的主从同步,时间久了Key多了,就得了解内存淘汰机制…… 他的大容量存储有问题,你可能需要去了解Pika…. 其实远远没完,每个的点我都点到为止,但是其实要深究每个点都要学很久,我们接着往下看。 实时/离线/大数据 等你把几种关系型非关系型数据库的知识点,整理清楚后,你会发现数据还是大啊,而且数据的场景越来越多多样化了,那大数据的各种中间件你就得了解了。 你会发现很多场景,不需要实时的数据,比如你查你的支付宝去年的,上个月的账单,这些都是不会变化的数据,没必要实时,那你可能会接触像ODPS这样的中间件去做数据的离线分析。 然后你可能会接触Hadoop系列相关的东西,比如于Hadoop(HDFS)的一个数据仓库工具Hive,是建立在 Hadoop 文件系统之上的分布式面向列的数据库HBase 。 写多的场景,适合做一些简单查询,用他们又有点大材小用,那Cassandra就再合适不过了。 离线的数据分析没办法满足一些实时的常见,类似风控,那Flink你也得略知一二,他的窗口思想还是很有意思。 数据接触完了,计算引擎Spark你是不是也不能放过…… 搜索引擎: 传统关系型数据库和NoSQL非关系型数据都没办法解决一些问题,比如我们在百度,淘宝搜索东西的时候,往往都是几个关键字在一起一起搜索东西的,在数据库除非把几次的结果做交集,不然很难去实现。 那全文检索引擎就诞生了,解决了搜索的问题,你得思考怎么把数据库的东西实时同步到ES中去,那你可能会思考到logstash去定时跑脚本同步,又或者去接触伪装成一台MySQL从服务的Canal,他会去订阅MySQL主服务的binlog,然后自己解析了去操作Es中的数据。 这些都搞定了,那可视化的后台查询又怎么解决呢?Kibana,他他是一个可视化的平台,甚至对Es集群的健康管理都做了可视化,很多公司的日志查询系统都是用它做的。 学习路线 看了这么久你是不是发现,帅丙只是一直在介绍每个层级的技术栈,并没说到具体的一个路线,那是因为我想让大家先有个认知或者说是扫盲吧,我一样用脑图的方式汇总一下吧,如果图片被平台二压了。 资料/学习网站 Tip:本来这一栏有很多我准备的资料的,但是都是外链,或者不合适的分享方式,博客的运营小姐姐提醒了我,所以大家去公众号回复【路线】好了。 絮叨 如果你想去一家不错的公司,但是目前的硬实力又不到,我觉得还是有必要去努力一下的,技术能力的高低能决定你走多远,平台的高低,能决定你的高度。 如果你通过努力成功进入到了心仪的公司,一定不要懈怠放松,职场成长和新技术学习一样,不进则退。 丙丙发现在工作中发现我身边的人真的就是实力越强的越努力,最高级的自律,享受孤独(周末的歪哥)。 总结 我提到的技术栈你想全部了解,我觉得初步了解可能几个月就够了,这里的了解仅限于你知道它,知道他是干嘛的,知道怎么去使用它,并不是说深入了解他的底层原理,了解他的常见问题,熟悉问题的解决方案等等。 你想做到后者,基本上只能靠时间上的日积月累,或者不断的去尝试积累经验,也没什么速成的东西,欲速则不达大家也是知道的。 技术这条路,说实话很枯燥,很辛苦,但是待遇也会高于其他一些基础岗位。 所实话我大学学这个就是为了兴趣,我从小对电子,对计算机都比较热爱,但是现在打磨得,现在就是为了钱吧,是不是很现实?若家境殷实,谁愿颠沛流离。 但是至少丙丙因为做软件,改变了家庭的窘境,自己日子也向小康一步步迈过去。 说做程序员改变了我和我家人的一生可能夸张了,但是我总有一种下班辈子会因为我选择走这条路而改变的错觉。 我是敖丙,一个在互联网苟且偷生的工具人。 创作不易,本期硬核,不想被白嫖,各位的「三连」就是丙丙创作的最大动力,我们下次见! 本文 GitHub https://github.com/JavaFamily 已经收录,有大厂面试完整考点,欢迎Star。 该回答来自:敖丙

剑曼红尘 2020-03-06 11:35:37 0 浏览量 回答数 0

回答

初识 MyBatis MyBatis 是第一个支持自定义 SQL、存储过程和高级映射的类持久框架。MyBatis 消除了大部分 JDBC 的样板代码、手动设置参数以及检索结果。MyBatis 能够支持简单的 XML 和注解配置规则。使 Map 接口和 POJO 类映射到数据库字段和记录。 MyBatis 的特点 那么 MyBatis 具有什么特点呢?或许我们可以从如下几个方面来描述 MyBatis 中的 SQL 语句和主要业务代码分离,我们一般会把 MyBatis 中的 SQL 语句统一放在 XML 配置文件中,便于统一维护。 解除 SQL 与程序代码的耦合,通过提供 DAO 层,将业务逻辑和数据访问逻辑分离,使系统的设计更清晰,更易维护,更易单元测试。SQL 和代码的分离,提高了可维护性。 MyBatis 比较简单和轻量 本身就很小且简单。没有任何第三方依赖,只要通过配置 jar 包,或者如果你使用 Maven 项目的话只需要配置 Maven 以来就可以。易于使用,通过文档和源代码,可以比较完全的掌握它的设计思路和实现。 屏蔽样板代码 MyBatis 回屏蔽原始的 JDBC 样板代码,让你把更多的精力专注于 SQL 的书写和属性-字段映射上。 编写原生 SQL,支持多表关联 MyBatis 最主要的特点就是你可以手动编写 SQL 语句,能够支持多表关联查询。 提供映射标签,支持对象与数据库的 ORM 字段关系映射 ORM 是什么?对象关系映射(Object Relational Mapping,简称ORM) ,是通过使用描述对象和数据库之间映射的元数据,将面向对象语言程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 提供 XML 标签,支持编写动态 SQL。 你可以使用 MyBatis XML 标签,起到 SQL 模版的效果,减少繁杂的 SQL 语句,便于维护。 MyBatis 整体架构 MyBatis 最上面是接口层,接口层就是开发人员在 Mapper 或者是 Dao 接口中的接口定义,是查询、新增、更新还是删除操作;中间层是数据处理层,主要是配置 Mapper -> XML 层级之间的参数映射,SQL 解析,SQL 执行,结果映射的过程。上述两种流程都由基础支持层来提供功能支撑,基础支持层包括连接管理,事务管理,配置加载,缓存处理等。 接口层 在不与Spring 集成的情况下,使用 MyBatis 执行数据库的操作主要如下: InputStream is = Resources.getResourceAsStream("myBatis-config.xml"); SqlSessionFactoryBuilder builder = new SqlSessionFactoryBuilder(); SqlSessionFactory factory = builder.build(is); sqlSession = factory.openSession(); 其中的SqlSessionFactory,SqlSession是 MyBatis 接口的核心类,尤其是 SqlSession,这个接口是MyBatis 中最重要的接口,这个接口能够让你执行命令,获取映射,管理事务。 数据处理层 配置解析 在 Mybatis 初始化过程中,会加载 mybatis-config.xml 配置文件、映射配置文件以及 Mapper 接口中的注解信息,解析后的配置信息会形成相应的对象并保存到 Configration 对象中。之后,根据该对象创建SqlSessionFactory 对象。待 Mybatis 初始化完成后,可以通过 SqlSessionFactory 创建 SqlSession 对象并开始数据库操作。 SQL 解析与 scripting 模块 Mybatis 实现的动态 SQL 语句,几乎可以编写出所有满足需要的 SQL。 Mybatis 中 scripting 模块会根据用户传入的参数,解析映射文件中定义的动态 SQL 节点,形成数据库能执行的SQL 语句。 SQL 执行 SQL 语句的执行涉及多个组件,包括 MyBatis 的四大核心,它们是: Executor、StatementHandler、ParameterHandler、ResultSetHandler。SQL 的执行过程可以用下面这幅图来表示 MyBatis 层级结构各个组件的介绍(这里只是简单介绍,具体介绍在后面): SqlSession: ,它是 MyBatis 核心 API,主要用来执行命令,获取映射,管理事务。接收开发人员提供 Statement Id 和参数。并返回操作结果。Executor :执行器,是 MyBatis 调度的核心,负责 SQL 语句的生成以及查询缓存的维护。StatementHandler : 封装了JDBC Statement 操作,负责对 JDBC Statement 的操作,如设置参数、将Statement 结果集转换成 List 集合。ParameterHandler : 负责对用户传递的参数转换成 JDBC Statement 所需要的参数。ResultSetHandler : 负责将 JDBC 返回的 ResultSet 结果集对象转换成 List 类型的集合。TypeHandler : 用于 Java 类型和 JDBC 类型之间的转换。MappedStatement : 动态 SQL 的封装SqlSource : 表示从 XML 文件或注释读取的映射语句的内容,它创建将从用户接收的输入参数传递给数据库的 SQL。Configuration: MyBatis 所有的配置信息都维持在 Configuration 对象之中。 基础支持层 反射模块 Mybatis 中的反射模块,对 Java 反射进行了很好的封装,提供了简易的 API,方便上层调用,并且对反射操作进行了一系列的优化,比如,缓存了类的 元数据(MetaClass)和对象的元数据(MetaObject),提高了反射操作的性能。 类型转换模块 Mybatis 的别名机制,能够简化配置文件,该机制是类型转换模块的主要功能之一。类型转换模块的另一个功能是实现 JDBC 类型与 Java 类型的转换。在 SQL 语句绑定参数时,会将数据由 Java 类型转换成 JDBC 类型;在映射结果集时,会将数据由 JDBC 类型转换成 Java 类型。 日志模块 在 Java 中,有很多优秀的日志框架,如 Log4j、Log4j2、slf4j 等。Mybatis 除了提供了详细的日志输出信息,还能够集成多种日志框架,其日志模块的主要功能就是集成第三方日志框架。 资源加载模块 该模块主要封装了类加载器,确定了类加载器的使用顺序,并提供了加载类文件和其它资源文件的功能。 解析器模块 该模块有两个主要功能:一个是封装了 XPath,为 Mybatis 初始化时解析 mybatis-config.xml配置文件以及映射配置文件提供支持;另一个为处理动态 SQL 语句中的占位符提供支持。 数据源模块 Mybatis 自身提供了相应的数据源实现,也提供了与第三方数据源集成的接口。数据源是开发中的常用组件之一,很多开源的数据源都提供了丰富的功能,如连接池、检测连接状态等,选择性能优秀的数据源组件,对于提供ORM 框架以及整个应用的性能都是非常重要的。 事务管理模块 一般地,Mybatis 与 Spring 框架集成,由 Spring 框架管理事务。但 Mybatis 自身对数据库事务进行了抽象,提供了相应的事务接口和简单实现。 缓存模块 Mybatis 中有一级缓存和二级缓存,这两级缓存都依赖于缓存模块中的实现。但是需要注意,这两级缓存与Mybatis 以及整个应用是运行在同一个 JVM 中的,共享同一块内存,如果这两级缓存中的数据量较大,则可能影响系统中其它功能,所以需要缓存大量数据时,优先考虑使用 Redis、Memcache 等缓存产品。 Binding 模块 在调用 SqlSession 相应方法执行数据库操作时,需要制定映射文件中定义的 SQL 节点,如果 SQL 中出现了拼写错误,那就只能在运行时才能发现。为了能尽早发现这种错误,Mybatis 通过 Binding 模块将用户自定义的Mapper 接口与映射文件关联起来,系统可以通过调用自定义 Mapper 接口中的方法执行相应的 SQL 语句完成数据库操作,从而避免上述问题。注意,在开发中,我们只是创建了 Mapper 接口,而并没有编写实现类,这是因为 Mybatis 自动为 Mapper 接口创建了动态代理对象。 MyBatis 核心组件 在认识了 MyBatis 并了解其基础架构之后,下面我们来看一下 MyBatis 的核心组件,就是这些组件实现了从 SQL 语句到映射到 JDBC 再到数据库字段之间的转换,执行 SQL 语句并输出结果集。首先来认识 MyBatis 的第一个核心组件 SqlSessionFactory 对于任何框架而言,在使用该框架之前都要经历过一系列的初始化流程,MyBatis 也不例外。MyBatis 的初始化流程如下 String resource = "org/mybatis/example/mybatis-config.xml"; InputStream inputStream = Resources.getResourceAsStream(resource); SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); sqlSessionFactory.openSession(); 上述流程中比较重要的一个对象就是SqlSessionFactory,SqlSessionFactory 是 MyBatis 框架中的一个接口,它主要负责的是 MyBatis 框架初始化操作 为开发人员提供SqlSession 对象 SqlSessionFactory 有两个实现类,一个是 SqlSessionManager 类,一个是 DefaultSqlSessionFactory 类 DefaultSqlSessionFactory : SqlSessionFactory 的默认实现类,是真正生产会话的工厂类,这个类的实例的生命周期是全局的,它只会在首次调用时生成一个实例(单例模式),就一直存在直到服务器关闭。 SqlSessionManager : 已被废弃,原因大概是: SqlSessionManager 中需要维护一个自己的线程池,而使用MyBatis 更多的是要与 Spring 进行集成,并不会单独使用,所以维护自己的 ThreadLocal 并没有什么意义,所以 SqlSessionManager 已经不再使用。 ####SqlSessionFactory 的执行流程 下面来对 SqlSessionFactory 的执行流程来做一个分析 首先第一步是 SqlSessionFactory 的创建 SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream); 1 从这行代码入手,首先创建了一个 SqlSessionFactoryBuilder 工厂,这是一个建造者模式的设计思想,由 builder 建造者来创建 SqlSessionFactory 工厂 然后调用 SqlSessionFactoryBuilder 中的 build 方法传递一个InputStream 输入流,Inputstream 输入流中就是你传过来的配置文件 mybatis-config.xml,SqlSessionFactoryBuilder 根据传入的 InputStream 输入流和environment、properties属性创建一个XMLConfigBuilder对象。SqlSessionFactoryBuilder 对象调用XMLConfigBuilder 的parse()方法,流程如下。 XMLConfigBuilder 会解析/configuration标签,configuration 是 MyBatis 中最重要的一个标签,下面流程会介绍 Configuration 标签。 MyBatis 默认使用 XPath 来解析标签,关于 XPath 的使用,参见 https://www.w3school.com.cn/xpath/index.asp 在 parseConfiguration 方法中,会对各个在 /configuration 中的标签进行解析 重要配置 说一下这些标签都是什么意思吧 properties,外部属性,这些属性都是可外部配置且可动态替换的,既可以在典型的 Java 属性文件中配置,亦可通过 properties 元素的子元素来传递。 <properties> <property name="driver" value="com.mysql.jdbc.Driver" /> <property name="url" value="jdbc:mysql://localhost:3306/test" /> <property name="username" value="root" /> <property name="password" value="root" /> </properties> 一般用来给 environment 标签中的 dataSource 赋值 <environment id="development"> <transactionManager type="JDBC" /> <dataSource type="POOLED"> <property name="driver" value="${driver}" /> <property name="url" value="${url}" /> <property name="username" value="${username}" /> <property name="password" value="${password}" /> </dataSource> </environment> 还可以通过外部属性进行配置,但是我们这篇文章以原理为主,不会介绍太多应用层面的操作。 settings ,MyBatis 中极其重要的配置,它们会改变 MyBatis 的运行时行为。 settings 中配置有很多,具体可以参考 https://mybatis.org/mybatis-3/zh/configuration.html#settings 详细了解。这里介绍几个平常使用过程中比较重要的配置 一般使用如下配置 <settings> <setting name="cacheEnabled" value="true"/> <setting name="lazyLoadingEnabled" value="true"/> </settings> typeAliases,类型别名,类型别名是为 Java 类型设置的一个名字。 它只和 XML 配置有关。 <typeAliases> <typeAlias alias="Blog" type="domain.blog.Blog"/> </typeAliases> 当这样配置时,Blog 可以用在任何使用 domain.blog.Blog 的地方。 typeHandlers,类型处理器,无论是 MyBatis 在预处理语句(PreparedStatement)中设置一个参数时,还是从结果集中取出一个值时, 都会用类型处理器将获取的值以合适的方式转换成 Java 类型。 在 org.apache.ibatis.type 包下有很多已经实现好的 TypeHandler,可以参考如下 你可以重写类型处理器或创建你自己的类型处理器来处理不支持的或非标准的类型。 具体做法为:实现 org.apache.ibatis.type.TypeHandler 接口, 或继承一个很方便的类 org.apache.ibatis.type.BaseTypeHandler, 然后可以选择性地将它映射到一个 JDBC 类型。 objectFactory,对象工厂,MyBatis 每次创建结果对象的新实例时,它都会使用一个对象工厂(ObjectFactory)实例来完成。默认的对象工厂需要做的仅仅是实例化目标类,要么通过默认构造方法,要么在参数映射存在的时候通过参数构造方法来实例化。如果想覆盖对象工厂的默认行为,则可以通过创建自己的对象工厂来实现。 public class ExampleObjectFactory extends DefaultObjectFactory { public Object create(Class type) { return super.create(type); } public Object create(Class type, List constructorArgTypes, List constructorArgs) { return super.create(type, constructorArgTypes, constructorArgs); } public void setProperties(Properties properties) { super.setProperties(properties); } public boolean isCollection(Class type) { return Collection.class.isAssignableFrom(type); } } 然后需要在 XML 中配置此对象工厂 <objectFactory type="org.mybatis.example.ExampleObjectFactory"> <property name="someProperty" value="100"/> </objectFactory> plugins,插件开发,插件开发是 MyBatis 设计人员给开发人员留给自行开发的接口,MyBatis 允许你在已映射语句执行过程中的某一点进行拦截调用。MyBatis 允许使用插件来拦截的方法调用包括:Executor、ParameterHandler、ResultSetHandler、StatementHandler 接口,这几个接口也是 MyBatis 中非常重要的接口,我们下面会详细介绍这几个接口。 environments,MyBatis 环境配置,MyBatis 可以配置成适应多种环境,这种机制有助于将 SQL 映射应用于多种数据库之中。例如,开发、测试和生产环境需要有不同的配置;或者想在具有相同 Schema 的多个生产数据库中 使用相同的 SQL 映射。 这里注意一点,虽然 environments 可以指定多个环境,但是 SqlSessionFactory 只能有一个,为了指定创建哪种环境,只要将它作为可选的参数传递给 SqlSessionFactoryBuilder 即可。 SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment); SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(reader, environment, properties); databaseIdProvider ,数据库厂商标示,MyBatis 可以根据不同的数据库厂商执行不同的语句,这种多厂商的支持是基于映射语句中的 databaseId 属性。 <databaseIdProvider type="DB_VENDOR"> <property name="SQL Server" value="sqlserver"/> <property name="DB2" value="db2"/> <property name="Oracle" value="oracle" /> </databaseIdProvider> mappers,映射器,这是告诉 MyBatis 去哪里找到这些 SQL 语句,mappers 映射配置有四种方式 上面的一个个属性都对应着一个解析方法,都是使用 XPath 把标签进行解析,解析完成后返回一个 DefaultSqlSessionFactory 对象,它是 SqlSessionFactory 的默认实现类。这就是 SqlSessionFactoryBuilder 的初始化流程,通过流程我们可以看到,初始化流程就是对一个个 /configuration 标签下子标签的解析过程。 SqlSession 在 MyBatis 初始化流程结束,也就是 SqlSessionFactoryBuilder -> SqlSessionFactory 的获取流程后,我们就可以通过 SqlSessionFactory 对象得到 SqlSession 然后执行 SQL 语句了。具体来看一下这个过程‘ 在 SqlSessionFactory.openSession 过程中我们可以看到,会调用到 DefaultSqlSessionFactory 中的 openSessionFromDataSource 方法,这个方法主要创建了两个与我们分析执行流程重要的对象,一个是 Executor 执行器对象,一个是 SqlSession 对象。执行器我们下面会说,现在来说一下 SqlSession 对象 SqlSession 对象是 MyBatis 中最重要的一个对象,这个接口能够让你执行命令,获取映射,管理事务。SqlSession 中定义了一系列模版方法,让你能够执行简单的 CRUD 操作,也可以通过 getMapper 获取 Mapper 层,执行自定义 SQL 语句,因为 SqlSession 在执行 SQL 语句之前是需要先开启一个会话,涉及到事务操作,所以还会有 commit、 rollback、close 等方法。这也是模版设计模式的一种应用。 MapperProxy MapperProxy 是 Mapper 映射 SQL 语句的关键对象,我们写的 Dao 层或者 Mapper 层都是通过 MapperProxy 来和对应的 SQL 语句进行绑定的。下面我们就来解释一下绑定过程 这就是 MyBatis 的核心绑定流程,我们可以看到 SqlSession 首先调用 getMapper 方法,我们刚才说到 SqlSession 是大哥级别的人物,只定义标准(有一句话是怎么说的来着,一流的企业做标准,二流的企业做品牌,三流的企业做产品)。 SqlSession 不愿意做的事情交给 Configuration 这个手下去做,但是 Configuration 也是有小弟的,它不愿意做的事情直接甩给小弟去做,这个小弟是谁呢?它就是 MapperRegistry,马上就到核心部分了。MapperRegistry 相当于项目经理,项目经理只从大面上把握项目进度,不需要知道手下的小弟是如何工作的,把任务完成了就好。最终真正干活的还是 MapperProxyFactory。看到这段代码 Proxy.newProxyInstance ,你是不是有一种恍然大悟的感觉,如果你没有的话,建议查阅一下动态代理的文章,这里推荐一篇 (https://www.jianshu.com/p/95970b089360) 也就是说,MyBatis 中 Mapper 和 SQL 语句的绑定正是通过动态代理来完成的。 通过动态代理,我们就可以方便的在 Dao 层或者 Mapper 层定义接口,实现自定义的增删改查操作了。那么具体的执行过程是怎么样呢?上面只是绑定过程,别着急,下面就来探讨一下 SQL 语句的执行过程。 MapperProxyFactory 会生成代理对象,这个对象就是 MapperProxy,最终会调用到 mapperMethod.execute 方法,execute 方法比较长,其实逻辑比较简单,就是判断是 插入、更新、删除 还是 查询 语句,其中如果是查询的话,还会判断返回值的类型,我们可以点进去看一下都是怎么设计的。 很多代码其实可以忽略,只看我标出来的重点就好了,我们可以看到,不管你前面经过多少道关卡处理,最终都逃不过 SqlSession 这个老大制定的标准。 我们以 selectList 为例,来看一下下面的执行过程。 这是 DefaultSqlSession 中 selectList 的代码,我们可以看到出现了 executor,这是什么呢?我们下面来解释。 Executor 还记得我们之前的流程中提到了 Executor(执行器) 这个概念吗?我们来回顾一下它第一次出现的位置。 由 Configuration 对象创建了一个 Executor 对象,这个 Executor 是干嘛的呢?下面我们就来认识一下 Executor 的继承结构 每一个 SqlSession 都会拥有一个 Executor 对象,这个对象负责增删改查的具体操作,我们可以简单的将它理解为 JDBC 中 Statement 的封装版。 也可以理解为 SQL 的执行引擎,要干活总得有一个发起人吧,可以把 Executor 理解为发起人的角色。 首先先从 Executor 的继承体系来认识一下 如上图所示,位于继承体系最顶层的是 Executor 执行器,它有两个实现类,分别是BaseExecutor和 CachingExecutor。 BaseExecutor 是一个抽象类,这种通过抽象的实现接口的方式是适配器设计模式之接口适配 的体现,是Executor 的默认实现,实现了大部分 Executor 接口定义的功能,降低了接口实现的难度。BaseExecutor 的子类有三个,分别是 SimpleExecutor、ReuseExecutor 和 BatchExecutor。 SimpleExecutor : 简单执行器,是 MyBatis 中默认使用的执行器,每执行一次 update 或 select,就开启一个Statement 对象,用完就直接关闭 Statement 对象(可以是 Statement 或者是 PreparedStatment 对象) ReuseExecutor : 可重用执行器,这里的重用指的是重复使用 Statement,它会在内部使用一个 Map 把创建的Statement 都缓存起来,每次执行 SQL 命令的时候,都会去判断是否存在基于该 SQL 的 Statement 对象,如果存在 Statement 对象并且对应的 connection 还没有关闭的情况下就继续使用之前的 Statement 对象,并将其缓存起来。因为每一个 SqlSession 都有一个新的 Executor 对象,所以我们缓存在 ReuseExecutor 上的 Statement作用域是同一个 SqlSession。 BatchExecutor : 批处理执行器,用于将多个 SQL 一次性输出到数据库 CachingExecutor: 缓存执行器,先从缓存中查询结果,如果存在就返回之前的结果;如果不存在,再委托给Executor delegate 去数据库中取,delegate 可以是上面任何一个执行器。 Executor 的创建和选择 我们上面提到 Executor 是由 Configuration 创建的,Configuration 会根据执行器的类型创建,如下 这一步就是执行器的创建过程,根据传入的 ExecutorType 类型来判断是哪种执行器,如果不指定 ExecutorType ,默认创建的是简单执行器。它的赋值可以通过两个地方进行赋值: 可以通过 标签来设置当前工程中所有的 SqlSession 对象使用默认的 Executor <settings> <!--取值范围 SIMPLE, REUSE, BATCH --> <setting name="defaultExecutorType" value="SIMPLE"/> </settings> 另外一种直接通过Java对方法赋值的方式 session = factory.openSession(ExecutorType.BATCH); Executor 的具体执行过程 Executor 中的大部分方法的调用链其实是差不多的,下面是深入源码分析执行过程,如果你没有时间或者暂时不想深入研究的话,给你下面的执行流程图作为参考。 我们紧跟着上面的 selectList 继续分析,它会调用到 executor.query 方法。 当有一个查询请求访问的时候,首先会经过 Executor 的实现类 CachingExecutor ,先从缓存中查询 SQL 是否是第一次执行,如果是第一次执行的话,那么就直接执行 SQL 语句,并创建缓存,如果第二次访问相同的 SQL 语句的话,那么就会直接从缓存中提取。 上面这段代码是从 selectList -> 从缓存中 query 的具体过程。可能你看到这里有些觉得类都是什么东西,我想鼓励你一下,把握重点,不用每段代码都看,从找到 SQL 的调用链路,其他代码想看的时候在看,看源码就是很容易发蒙,容易烦躁,但是切记一点,把握重点。 上面代码会判断缓存中是否有这条 SQL 语句的执行结果,如果没有的话,就再重新创建 Executor 执行器执行 SQL 语句,注意, list = doQuery 是真正执行 SQL 语句的过程,这个过程中会创建我们上面提到的三种执行器,这里我们使用的是简单执行器。 到这里,执行器所做的工作就完事了,Executor 会把后续的工作交给 StatementHandler 继续执行。下面我们来认识一下 StatementHandler 上面代码会判断缓存中是否有这条 SQL 语句的执行结果,如果没有的话,就再重新创建 Executor 执行器执行 SQL 语句,注意, list = doQuery 是真正执行 SQL 语句的过程,这个过程中会创建我们上面提到的三种执行器,这里我们使用的是简单执行器。 到这里,执行器所做的工作就完事了,Executor 会把后续的工作交给 StatementHandler 继续执行。下面我们来认识一下 StatementHandler StatementHandler 的继承结构 有没有感觉和 Executor 的继承体系很相似呢?最顶级接口是四大组件对象,分别有两个实现类 BaseStatementHandler 和 RoutingStatementHandler,BaseStatementHandler 有三个实现类, 他们分别是 SimpleStatementHandler、PreparedStatementHandler 和 CallableStatementHandler。 RoutingStatementHandler : RoutingStatementHandler 并没有对 Statement 对象进行使用,只是根据StatementType 来创建一个代理,代理的就是对应Handler的三种实现类。在MyBatis工作时,使用的StatementHandler 接口对象实际上就是 RoutingStatementHandler 对象。 BaseStatementHandler : 是 StatementHandler 接口的另一个实现类,它本身是一个抽象类,用于简化StatementHandler 接口实现的难度,属于适配器设计模式体现,它主要有三个实现类 SimpleStatementHandler: 管理 Statement 对象并向数据库中推送不需要预编译的SQL语句。PreparedStatementHandler: 管理 Statement 对象并向数据中推送需要预编译的SQL语句。CallableStatementHandler:管理 Statement 对象并调用数据库中的存储过程。 StatementHandler 的创建和源码分析 我们继续来分析上面 query 的调用链路,StatementHandler 的创建过程如下 MyBatis 会根据 SQL 语句的类型进行对应 StatementHandler 的创建。我们以预处理 StatementHandler 为例来讲解一下 执行器不仅掌管着 StatementHandler 的创建,还掌管着创建 Statement 对象,设置参数等,在创建完 PreparedStatement 之后,我们需要对参数进行处理了。 如 如果用一副图来表示一下这个执行流程的话我想是这样 这里我们先暂停一下,来认识一下第三个核心组件 ParameterHandler ParameterHandler - ParameterHandler 介绍 ParameterHandler 相比于其他的组件就简单很多了,ParameterHandler 译为参数处理器,负责为 PreparedStatement 的 sql 语句参数动态赋值,这个接口很简单只有两个方法 ParameterHandler 只有一个实现类 DefaultParameterHandler , 它实现了这两个方法。 getParameterObject: 用于读取参数setParameters: 用于对 PreparedStatement 的参数赋值ParameterHandler 的解析过程 上面我们讨论过了 ParameterHandler 的创建过程,下面我们继续上面 parameterSize 流程 这就是具体参数的解析过程了,下面我们来描述一下 下面用一个流程图表示一下 ParameterHandler 的解析过程,以简单执行器为例 我们在完成 ParameterHandler 对 SQL 参数的预处理后,回到 SimpleExecutor 中的 doQuery 方法 上面又引出来了一个重要的组件那就是 ResultSetHandler,下面我们来认识一下这个组件 ResultSetHandler - ResultSetHandler 简介 ResultSetHandler 也是一个非常简单的接口 ResultSetHandler 是一个接口,它只有一个默认的实现类,像是 ParameterHandler 一样,它的默认实现类是DefaultResultSetHandler ResultSetHandler 解析过程 MyBatis 只有一个默认的实现类就是 DefaultResultSetHandler,DefaultResultSetHandler 主要负责处理两件事 处理 Statement 执行后产生的结果集,生成结果列表 处理存储过程执行后的输出参数 按照 Mapper 文件中配置的 ResultType 或 ResultMap 来封装成对应的对象,最后将封装的对象返回即可。 其中涉及的主要对象有: ResultSetWrapper : 结果集的包装器,主要针对结果集进行的一层包装,它的主要属性有 ResultSet : Java JDBC ResultSet 接口表示数据库查询的结果。 有关查询的文本显示了如何将查询结果作为java.sql.ResultSet 返回。 然后迭代此ResultSet以检查结果。 TypeHandlerRegistry: 类型注册器,TypeHandlerRegistry 在初始化的时候会把所有的 Java类型和类型转换器进行注册。 ColumnNames: 字段的名称,也就是查询操作需要返回的字段名称 ClassNames: 字段的类型名称,也就是 ColumnNames 每个字段名称的类型 JdbcTypes: JDBC 的类型,也就是 java.sql.Types 类型 ResultMap: 负责处理更复杂的映射关系 在 DefaultResultSetHandler 中处理完结果映射,并把上述结构返回给调用的客户端,从而执行完成一条完整的SQL语句。 内容转载自:CSDN博主:cxuann 原文链接:https://blog.csdn.net/qq_36894974/article/details/104132876?depth_1-utm_source=distribute.pc_feed.none-task&request_id=&utm_source=distribute.pc_feed.none-task

问问小秘 2020-03-05 15:44:27 0 浏览量 回答数 0

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。

hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

问题

【精品问答】python技术1000问(2)

问问小秘 2019-12-01 22:03:02 3129 浏览量 回答数 1

问题

【精品问答】110+数据挖掘面试题集合

珍宝珠 2019-12-01 21:56:45 2713 浏览量 回答数 3
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 企业信息查询 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站