资源分时系统工作原理

说实话这乱七八糟一堆文字我看了两边,然后发现真救不了你. ######回复 @刘子玄:操作系统不管理寄存器，现在都是抢占式多线程操作系统，都是在线程释放资源的时候切换到其他进程的(你调用某些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有那么简单么…………######这个你放心，我只会把编程当成毕生的爱好，而不会用作工作。

说实话这乱七八糟一堆文字我看了两边,然后发现真救不了你. ######回复 @刘子玄 : 操作系统不管理寄存器，现在都是抢占式多线程操作系统，都是在线程释放资源的时候切换到其他进程的(你调用某些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有那么简单么…………######这个你放心，我只会把编程当成毕生的爱好，而不会用作工作。

1，架构师是什么？要想往架构师的方向发展首先要知道架构师是什么？架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。架构师在软件开发的整个过程中起着很重要的作用。说的详细一些，架构师就是确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。2，架构师的任务架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。在成为Java架构师之前，应当先成为Java工程师。熟练使用各种框架，并知道它们实现的原理。jvm虚拟机原理、调优，懂得jvm能让你写出性能更好的代码；池技术，什么对象池，连接池，线程池……Java反射技术，写框架必备的技术，遇到有严重的性能问题，替代方案java字节码技术；nio，没什么好说的，值得注意的是"直接内存"的特点，使用场景；java多线程同步异步；java各种集合对象的实现原理，了解这些可以让你在解决问题时选择合适的数据结构，高效的解决问题，比如hashmap的实现原理，好多五年以上经验的人都弄不清楚，还有为什扩容时有性能问题？不弄清楚这些原理，就写不出高效的代码，还会认为自己做的很对；总之一句话，越基础的东西越重要，很多人认为自己会用它们写代码了，其实仅仅是知道如何调用api而已,离会用还差的远。如果你立志做架构，首先打好基础，从最底层开始。然后发展到各种技术和语言，什么都要懂两点，要全面且不肤浅。为什么不是懂一点？你要看得透彻，必须尽量深入一些。别人懂一点，你要做架构师，必须再多懂一点。比如你发现golang很流行，别人可能写一个helloworld就说自己玩过golang，但你至少要尝试写一个完整的应用。不肯下苦功，如何高人一头？另外你要非常深入地了解至少一门语言，如果你的目标是java，就学到极致，作为敲门砖，先吃饱了才能谈理想。3，架构师都是从码农过来的而Java学到极致势必涉及到设计模式，算法和数据结构，多线程，文件及网络IO，数据库及ORM，不一而足。这些概念放之一切语言都适用。先精一门，为全面且不肤浅打基础。另外就是向有经验的架构师学习，和小伙伴们讨论辩论争论。其实最重要的能力就是不断学习。在思考新的技术是否能更好地解决你们遇到的问题之前，你首先得知道并了解新的技术。架构师都是从码农过来的，媳妇熬成婆。千万不要成为不写代码的架构师，有些公司专门产不写技术的架构师。所谓架构师，只是功底深厚的程序员而已。个人认为应该扎扎实实学习基础知识，学习各种规范，架构，需要广泛的知识面，懂的东西越多视野越开阔，设计的东西当然会越好越全面。成为架构师需要时间的积累的，不但要知其然还要知其所以然。平时的一点一滴你感觉不到特别用处，但某天你会发现所有东西都没有白学的。4，架构师知识体系下面是我总结多年经验开发的架构师知识体系一、分布式架构架构分布式的英文（ Distributed computing 分布式计算技术）的应用和工具，成熟目前的技术包括 J2EE，CORBA 和 .NET（DCOM），这些技术牵扯的内容非常广，相关的书籍也非常多。本文不介绍这些技术的内容，也没有涉及这些技术的细节，只是从各种分布式系统平台产生的背景和在软件开发中应用的情况来探讨它们的主要异同。分布式系统是一个古老而宽泛的话题，而近几年因为“大数据”概念的兴起，又焕发出了新的青春与活力。除此之外，分布式系统也是一门理论模型与工程技法。并重的学科内容相比于机器学习这样的研究方向，学习分布式系统的同学往往会感觉：“入门容易，深入难”的确，学习分布式系统几乎不需要太多数学知识。分布式系统是一个复杂且宽泛的研究领域，学习一两门在线课程，看一两本书可能都是不能完全覆盖其所有内容的。总的来说，分布式系统要做的任务就是把多台机器有机的组合，连接起来，让其协同完成一件任务，可以是计算任务，也可以是存储任务。如果一定要给近些年的分布式系统研究做一个分类的话，我个人认为大概可以包括三大部分：分布式存储系统分布式计算系统分布式管理系统二、微服务当前微服务很热，大家都号称在使用微服务架构，但究竟什么是微服务架构？微服务架构是不是发展趋势？对于这些问题，我们都缺乏清楚的认识。为解决单体架构下的各种问题，微服务架构应运而生。与其构建一个臃肿庞大，难以驯服的怪兽，还不如及早将服务拆分。微服务的核心思想便是服务拆分与解耦，降低复杂性。微服务强调将功能合理拆解，尽可能保证每个服务的功能单一，按照单一责任原则（Single Responsibility Principle）明确角色。将各个服务做轻，从而做到灵活，可复用，亦可根据各个服务自身资源需求，单独布署，单独作横向扩展。微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多 SOLID 原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发，管理和迭代在分散的组件中使用云架构和平台式部署，管理和服务功能，使产品交付变得更加简单。本质：用一些功能比较明确，业务比较精练的服务去解决更大，更实际的问题。三、源码分析从字面意义上来讲，源文件的英文指一个文件，指源代码的集合。源代码则是一组具有特定意义的可以实现特定功能的字符（程序开发代码）。源码分析是一种临界知识，掌握了这种临界知识，能不变应万变，源码分析对于很多人来说很枯燥，生涩难懂。源码阅读，我觉得最核心有三点：技术基础+强烈的求知欲+耐心。我认为是阅读源码的最核心驱动力我见到绝大多数程序员，对学习的态度，基本上就是这几个层次（很偏激哦）：1，只关注项目本身，不懂就百度一下。2，除了做好项目，还会阅读和项目有关的技术书籍，看维基百科。3，除了阅读和项目相关的书外，还会阅读IT行业的书，比如学的Java的时，还会去了解函数语言，如LISP。4，找一些开源项目看看，大量试用第三方框架，还会写写演示。5，阅读基础框架，J2EE 规范，调试服务器内核。大多数程序都是第1种，到第5种不光需要浓厚的兴趣，还需要勇气：？我能读懂吗其实，你能够读懂的耐心，真的很重要。因为你极少看到阅读源码的指导性文章或书籍，也没有人要求或建议你读。你读的过程中经常会卡住，而一卡主可能就陷进了迷宫这时，你需要做的，可能是暂时中断一下，再从外围看看它：如API结构，框架的设计图。四、工具使用工欲善其事必先利其器，工具对 Java 的的程序员的重要性不言而喻现在有很多库，实用工具和程序任的 Java 的开发人员选择。下图列出的工具都是程序员必不可少的工具五、性能优化不管是应付前端面试还是改进产品体验，性能优化都是躲不开的话题。优化的目的是让用户有“快”的感受，那如何让用户感受到快呢？加载速度真的很快，用户打开输入网址按下回车立即看到了页面加载速度并没有变快，但用户感觉你的网站很快性能优化取决于多个因素，包括垃圾收集，虚拟机和底层操作系统（OS）设置。有多个工具可供开发人员进行分析和优化时使用，你可以通过阅读爪哇工具的源代码优化和分析来学习和使用它们。必须要明白的是，没有两个应用程序可以使用相同的优化方式，也没有完美的优化的 Java 应用程序的参考路径。使用最佳实践并且坚持采用适当的方式处理性能优化。想要达到真正最高的性能优化，你作为一个 Java 的开发人员，需要对 Java 的虚拟机（JVM）和底层操作系统有正确的理解。性能优化，简而言之，就是在不影响系统运行正确性的前提下，使之运行地更快，完成特定功能所需的时间更短。性能问题永远是永恒的主题之一，而优化则更需要技巧。Java程序员如何学习才能快速入门并精通呢？当真正开始学习的时候难免不知道从哪入手，导致效率低下影响继续学习的信心。但最重要的是不知道哪些技术需要重点掌握，学习时频繁踩坑，最终浪费大量时间，所以有一套实用的视频课程用来跟着学习是非常有必要的。为了让学习变得轻松、高效，今天给大家免费分享一套阿里架构师传授的一套教学资源。帮助大家在成为架构师的道路上披荆斩棘。这套视频课程详细讲解了（Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构）等这些成为架构师必备的内容！而且还把框架需要用到的各种程序进行了打包，根据基础视频可以让你轻松搭建分布式框架环境，像在企业生产环境一样进行学习和实践。

数据库课程设计 “数据库课程设计”是数据库系统及应用课程的后续实验课，是进一步巩固学生的数据库知识，加强学生的实际动手能力和提高学生综合素质。 一、 课程设计目的 课程设计为学生提供了一个既动手又动脑，独立实践的机会，将课本上的理论知识和实际有机的结合起来，锻炼学生的分析解决实际问题的能力。提高学生适应实际，实践编程的能力。课程设计的目的： 1. 加深对数据库原理、程序设计语言的理论知识的理解和应用水平； 2. 在理论和实验教学基础上进一步巩固已学基本理论及应用知识并加以综合提高； 3. 学会将知识应用于实际的方法，提高分析和解决问题的能力，增强动手能力； 4. 为毕业设计和以后工作打下必要基础。 二、课程设计要求 运用数据库原理的基本理论与应用知识，在微机RDBMS(SQL Server)的环境上建立一个数据库应用系统。要求把现实世界的事物及事物之间的复杂关系抽象为信息世界的实体及实体之间联系的信息模型，再转换为机器世界的数据模型和数据文件，并对数据文件实施检索、更新和控制等操作。 1. 用E-R图设计选定题目的信息模型； 2. 设计相应的关系模型，确定数据库结构； 3. 分析关系模式各属于第几范式，阐明理由； 4. 设计应用系统的系统结构图，确定系统功能； 5. 通过设计关系的主码约束、外码约束和使用CHECK实现完整性控制； 6. 为参照关系设计插入、删除、修改触发器； 7. 实现应用程序设计、编程、优化功能； 8. 对系统的各个应用程序进行集成和调试，进一步优化系统功能、改善系统用户界面完成实验内容所指定的各项要求； 9. 分析遇到的问题，总结并写出课程设计报告； 10. 自我评价 三、实验环境 开发环境VC++、C#、ASP或JAVA；ODBC/JDBC；数据库SQL Server 四、上机实现内容 1. 创建数据库的结构 2. 创建各基本表的结构 3. 编制系统各功能模块，完成数据的管理（增、删、改）及统计查询。对于程序运行界面不做考核的重点。 五、课程设计考核 1.对学生到实验室的情况进行不定时统计； 2.出勤率+课程设计报告+课程设计所开发的应用系统+其他（上机抽查和提问）=综合评定成绩。 3.课程设计结束时请将下列资料上交： （1） 课程设计报告； （2） 所开发的应用系统的源程序、安装和使用说明； （3） 将（1）（2）中的资料压缩成一个压缩包，压缩包文件的命名规则：班级+学号（末2位）+姓名（例如：计科090101王鹏晓）； （4） 班长将本班每人的（3）中的压缩包刻录成光盘连同打印的课程设计报告收齐，交给任课教师。 附录﹑课程设计题目 题目1：课程设计选题管理系统（1，24） 包括三大模块：  课程设计题目维护与查询：题目的添加、修改和删除；按题目类型、名称和关键字查询以及已选与未选题目的查询；  学生信息维护与查询；  学生选题维护与管理：学生选题及查询； 具体功能细化：  前台学生选题：学生上网登录系统进行选题；  前台教师出题：  教师添加、修改和删除题目；  教师确认学生的选题；  后台管理出题和选题  添加用户及权限 题目2：书店管理系统（23） 包括四大模块：  售书（图书销售管理及销售统计，查询）  进书（通过书目，向发行商下定单订购图书）  库存（图书库存，统计）  相关查询 题目3：图书馆管理系统（11） 包括四大模块：  图书的查询  借书  还书  图书的预约 题目4：库存管理系统（8） 包括四大模块：  商品目录建立  商品入库管理  商品出库管理  商品库存查询 题目5：工资管理系统（1 人）41 包括四大模块：  系统数据初始化  员工基本信息数据的输入、修改、删除；  员工个人信息及工资表的查询；  员工工资的计算； 参考数据如下：  员工基本状况：包括员工号、员工姓名、性别、所在部门、工资级别、工资等级等。  工资级别和工资金额：包括工资等级、工资额。  企业部门及工作岗位信息：包括部门名称、工作岗位名称、工作岗位工资等。  工龄和工资金额：包括工龄及对应工资额。  公司福利表：包括福利名称、福利值。  工资信息：包括员工号、员工姓名、员工基础工资、员工岗位工资、员工工龄工资、公司福利、员工实得工资。 题目6：酒店客房管理系统 （1 人）14，26 包括四大模块：  前台操作：包括开房登记、退房结账和房状态查看  预订管理：包括预订房间、预订入住和解除预订  信息查询：包括在住客人列表、预订客人列表和历史客人列表  报表统计：包括开房记录统计、退房结账和预订房间统计  员工基本信息数据的输入、修改、删除； 参考数据如下：  住店管理：客人姓名、证件号码、房号、入住时期、预计离开日期、结账离开日期、应付金额  客人信息：姓名、性别、证件类型、证件号码、联系电话  房间信息：房号、房类型、价格、押金、房状态 预订房间  客人姓名、性别、房类型、房号、价格、证件类型、证件号码、联系电话、入住日期、预计离开日期、历史信息 题目7：旅行社管理信息系统（1 人）3 包括如下模块：  旅游团队、团队团员及旅游路线相关信息的输入  旅游团队、团队团员及旅游路线相关信息的维护（修改、浏览、删除和撤销）  旅游团队管理信息的查询（如按团队编号）  团队团员基本情况的查询（可选多种方式）  旅游路线相关信息的查询（如按线路编号）  旅游路线排行榜发布。  数据备份，更改密码。 参考数据如下：  团员信息表（路线编号，团队编号，团员编号，姓名，性别，电话，通信地址，身份证号码， 团费交否，备注）  线路信息表（路线名称，团费，简介，图形，路线编号）  团队信息表（团队编号，路线编号，团员人数，出发日期，返程日期）  旅游团队信息表（团队编号，团队负责人，团员人数，建团时间，是否出发，团费，盈亏） 密码信息（操作员，密码） 题目8：报刊订阅管理系统 （1 人）25，35 包括如下模块：  登录功能：登录统为身份验证登录。分为管理员登录和一般用户登录。分别通过不 同的用户名和密码进入报刊订阅管理界面，新的用户需要注册。  录入新信息功能：对于管理员，包括新用户信息和新报刊信息的录入功能，信息一旦 提交就存入到后台数据库中；普通用户自行注册进行可以修改个人信息。  订阅功能：用户可以订阅报刊，系统自动计算所需金额，并显示在界面上；管理员不 可订阅报刊，必须以用户身份订阅报刊。  查询功能：用户可以查询并显示自己所订阅的信息；管理员可以按人员、报刊、部门 分类查询。查询出的信息显示在界面上,并且可以预览和打印出结果。  统计功能：管理员可以按用户、部门、报刊统计报刊的销售情况，并对一些重要的订 阅信息进行统计；普通用户可以统计出自己的订阅情况，并且可以预览和打印出结果。  系统维护功能：数据的安全管理，主要是依靠管理员对数据库里的信息进行备份和恢 复，数据库备份后，如果出了什么意外可以恢复数据库到当时备份的状态，这提高了系统和 数据的安全性，有利于系统的维护 参考数据如下：  管理员表（Adminuser） ：管理员名、密码。  部门表（Department） ：部门号，部门名。  用户表（Users） ：用户账号、密码、真实姓名、身 份证号、联系电话，联系地址，部门号（和部门表有关）等。  报刊类别表（NewspaperClass） ：分类编号、 分类名称。  报刊信息表（Newspaper） ：报刊代号、报刊名称、出版 报社、出版周期、季度报价、内容介绍、分类编号（和报刊类别表有关）等。  订单表（Order） ：订单编号、用户编号、报刊代号、订阅份数、订阅月数等。 题目9：计算机等级考试教务管理系统（2 人）32 包括四大模块：  用户设置：对考点代码，考点名称进行设置，设置用户与密码；系统复位：即清除上一次考试数据（在之前存入历史）  报名管理： 报各库录入（姓名不能不空，之间不能有空格） 增加、删除、修改、浏览  准考证管理：准考证生成规则：xxx+yy+zz+kk，其中 XXX 为考点代码；YY 为语言代码，XX 为考场号，KK 为座位号 同一级别、语言应根据报名初始库信息按随机数生成准考证，同一考点最多可有 99*30=2970 名考生；如已生成准考证号，再重新生成准考证号，应该给予提示。 准考证打印  考务管理：考生信息查询、浏览、打印  成绩管理：成绩数据录入、接收 成绩合成（总成绩=笔试成绩*0.6+上机成绩*0.4）,按大于或等于 60 合格 参考数据如下：  初始报名表（准考证号（为空） ，报名号（主键） ，级别+语言种类（外键） ，姓名，性别， 出生年份，民族，身份证号，联系地址，联系电话，照片，备注，参加培训）  含准考证号的报名表（准考证号（为主键） ，报名号，级别+语言种类（外键） ，姓名，性别， 出生年份，民族，身份证号，联系地址，联系电话，照片，备注，参加培训）  成绩表（准考证号，笔试成绩，上机成绩，总成绩） 级别语言代码表（级别语言代码，级别+语言）  用户信息表（考点代码，考点名称，用户名，密码） 题目10：人事管理系统（1 人）21 包括四大模块：  登录管理：包括操作员管理，口令设置，权限管理  人员管理：包括人事数据维护、人事信息查询和人事信息统计  工资管理  部门管理：包括部门表，职称表和年份表  查询及报表打印 参考数据如下：  人事表（编号，姓名，性别，出生日期，工作日期，部门代码，职称，婚否，简历，相片）  工资表（基本工资，岗位津贴，奖励，应发工资，水电，保险，实发工资）  部门表（代码，部门名称）  职称表（职称代码，职称名称）  年份表（年份代码，年份名称）  操作员表（操作员代码，操作员姓名，口令，部门，电话） 系统日志表（操作员代号，操作员姓名，登录时间，离开时间） 题目11：商品销售管理系统（1 人）19 包括四大模块：  用户登录  基本信息管理：包括销售情况、商品信息、库存表、员工表等信息的录入、浏览、修改、撤销、删除和查询等  商品销售管理：包括商品售出、退回和入库  盘点：包括库存盘点、当日销售盘点 参考数据如下：  商品信息表（商品编号，商品名称，品牌，型号，销售单价） 商品编号=类别代码（1 位）+品名代码（1 位）+品牌代码（2 位）+型号代码（2 位）  销售情况表（成交编号，商品编号，销售数量，总金额，销售日期，员工编号）  库存表（商品编号，供货商编号，进货日期，进货价，库存数量）  员工表（员工编号，员工姓名，性别，基本工资，职务，密码）  供货商表（供货商编号，供货商名称，所在地，联系电话）  员工资料表（员工编号，员工姓名，是否党员，简历，照片） 题目12：学生成绩管理系统（1 人）29 包括四大模块：  基本数据管理：包括院系管理，专业管理（设置院系下面的专业），班级管理（设置专业下面的班级），课程管理（设置相应专业下面的课程）  学生信息管理：包括基本信息录入、基本信息修改  学生成绩管理：包括学生成绩录入、学生成绩修改  信息查询：包括基本信息查询、成绩信息查询、学校人数统计  系统管理：用户管理、数据备份和系统帮助 参考数据如下：  院系信息（院系代码，院系名称）  院系专业信息（班级、院系代码，专业）  学生基本信息（班号，学号，姓名，性别，出生年月，籍贯，政治面貌，身份证号，入学年月，家庭地址，邮政编码，图片信息，备注）  学生成绩表（学号，课号，成绩，备注）  课程表（课号，课程名称，学期，备注）  班表（班号，班级名称）  用户信息表（用户名，密码，用户标识） 题目13：火车售票管理系统（4 人）36 包括四大模块：  售票管理  订票管理  信息查询  系统维护 参考数据如下：  车次信息表（车次，始发站，终点站，发车时间，到达时间）  订票信息表（车次，座位号，发车时期，发车时间，座位等级，票价）  车次座位等级分配及座位占用表（车次，座位号，座位等级，票价，占用标志）  用户信息表（用户名，密码，用户标识） 题目14：小型物业管理系统（1 人） 包括四大模块：  房源管理：对原始资料的录入、修改、查询和刷新。一般用户可以查询与房间有关 的统计资料；物业主管可其进行增、删、改、插等操作  租房管理：对房产出租，退租以及租房面积调整。其中物业主管可对其进行房租金 额计算和收款操作，一般用户对其查询  水电处理：根据租房资料，结合当月水、电量进行分摊，完成应收水电费。其中物 业主管对其进行计算，其他查询  交款处理：提供收款和发票打印以及交款数据查询  查询处理：对租房资料、交款资料，发票资料进行查询 参考数据如下：  房源资料（名称，面积，月租，物业，仓库）  租房资料（名称，面积，单位，月租，物业，押金，仓库）  水电资料（单位，电量，水量，电费，水费）  交费资料（收费项目，应收日期，应收金额，已收金额，未收金额，本次收款）  发票资料（单位，房租，电费，水费，物业）  权限资料（用户，密码，房源管理，租房管理，水电管理，交费管理，发票管理，系统维护） 其中系统管理员，有权进行系统维护；单位内部物业主管，有权进行物业资源调配、单元出 租，退租和收款开票操作；物业管理员，有权进行水电处理和收款处理等操行；租户代表， 有权进行种类费的查询操作 题目15：机房收费管理系统（1 人）7，34 包括四大模块：  登录模块  上机管理模块 说明：上机登记时，余额不足 3 元或卡处于挂失状态，则拒绝登记 每位同学的一次上机形成一条记录，每 36S 遍历一次上机记录表，对表中所有正上机字段为 TRUE 的记录的上机用时增加 36S,同时从上机卡表的余额减少  上机卡管理模块  充值挂失模块  查找统计模块：统计某天上机的总时数、每次上机的平均时数和机房的收入；某学 生上机的次数、上机总时数、每次上机平均时间；挂失和查询余 参考数据如下：  上机卡（卡号，姓名，专业班级，余额，状态） 状态的取值有：正常（能自费上机）  挂失上机记录（卡号，上机日期，开始时间，上机用时，正上机，管理号代码），上机用时记录学生上机时间（S）；正上机是一个布尔型，为 True 表示正上机，每 36 秒刷新 其上机用时并扣除上机费用，为 False 表示上机结束。上机记录表永久保存，用于事后查询 和统计 管理员（代码，姓名，口令）  题目16：高校药房管理（1 人）31 包括四大模块：  基础数据处理：包括医生和药剂师名单的录入，修改，删除及查询  营业数据处理：包括药品进货上柜，处理划价，配药，柜存药品查询，处方综合查 询，交接班结转清。 参考数据如下：  药品信息表（货号，货名，计量单位，进货数量，进货单价，出售单价，进货日期，收货人 和供应商）  处方信息（编号，患者姓名，医生姓名，药剂师姓名，处方日期，配药日期） 处方药品信息（处方编号，药品货号，计量单位，配药数量，销售单价，已配药否）  医生名单和药剂师名单表（姓名）  题目17：考勤管理系统（2 人）40 包括四大模块：  记录每个员工每天所有进入公司的时刻和离开公司的时刻。  每天结束时自动统计当天的工作时间  每天结束时自动统计当天迟到或早退的次数。  对于弹性工作制，每天结束时自动统计当月的工时，并自动算出当月欠缺或富余的 时间  每个月末统计该月的工作时间判断是束足够  每个月末统计该月的工作天数并判断是否足够  管理人员查询并修改工作时间（特殊情况下修改）  管理人员账户管理（如设置密码等）  管理人员设定早退及迟到的条件，每个月的工作时间  管理人员设定每个月的工作日期及放假日期 参考数据如下：  员工信息(工号，姓名，年龄，入职时间，职位，性别，密码)  配置信息（上班时间小时，上班时间分钟，下班时间小时，下班时间分钟，每天工作时间）  每月统计数据表（工号，姓名，剩余的时间，迟到的次数，早退的次数，工作天数）  每天统计信息表（工号，姓名，小时，分钟，动作，时间） 其中动作指的时入或离开公司  题目18：单位房产管理系统（2 人）33，10 包括四大模块：  系统模块：完成数据库维护、系统关闭功能  物业费用模块：完成本月物业的计费、历史资料查询和财务部门接口传送数据、物 业相关费用单价设置  房屋资源模块：对房屋资源进行添加、列表显示、查询  职工信息模块：对职工进行添加、列表显示、查询以及相应部门、职务进行维护  帮助模块：对用户使用本系统提供在线帮助 参考数据如下：  职工（编号，姓名，性别，参加工作时间，行政职务，专业技术职务，评上最高行政职务时 间，评上最高专业技术职务时间，双职工姓名，现居住房号，档案号，房产证号，所在部门 编号，是否为户主）  部门（编号，部门名称） 住房级别表（编号，级别，住房标准，控制标准，级别分类）  房产情况（编号，房号，使用面积，现居住人 id，上一个居住人 id,最早居住人 ID,阳台面积）  物业费用（编号，房号，水基数，水现在值，电基数，电现在值，燃气基数，燃气现在值， 当前年份，当前月份）  价格标准（编号，水单价，电单价，燃气单价） 题目19：标准化考试系统 （2 人）15，39 功能要求： 设计一个简单的标准化考试系统，仅有单项选择题、多项选择题和判断题功能即可。 包括四大模块：  题库管理：实现试题的录入、修改、删除功能；  考试子系统：能够实现考生做题、结果自动存入到数据库中，有时间提示；  选择身份(登录)功能：系统能够记录考生输入的登录信息及交卷信息；  自动评分功能：考生交卷后能自动评分；  查看成绩功能：能够查询考生相关信息(包含成绩等)。 参考数据如下： 其它可供选择的题目： 网上教务评教系统130，127，133 16 学生日常行为评分管理系统232，110，230 网上鲜花店 38 基于BS结构的工艺品销售系统12 基于BS结构的校园二手物品交易网站 37 大学生就业管理系统201，208，234 题库及试卷管理系统 数据库原理及应用 课程设计报告 题目： 课程设计选题管理系统 所在学院： 班 级： 学 号： 姓 名： 李四 指导教师： 2011年12月 日 目录 一、 概述 二、需求分析 三、概念设计 四、逻辑设计 五、系统实现 六、小结 一、概述

A－GPS全称是网络辅助的GPS定位（AGPS） 比较实用的GPS定位技术是网络辅助的GPS定位，即定位时，网络将GPS卫星信息（如星历表）传送给移动台，移动台利用这些信息可以快速的搜索到有效的GPS卫星，接收到卫星信号后，计算移动台位置的工作可以由网络实体（如PDE）或移动台完成 ?v?t?g;V?E0T?N2m A－GPS技术是一种结合了网络基站信息和GPS信息对移动台进行定位的技术，可以在GSM/GPRS、WCDMA和CDMA2000网络中使用。该技术需要在手机内增加GPS接收机模块，并改造手机天线，同时要在移动网络上加建位置服务器、差分GPS基准站等设备。如果要提高该方案在室内等GPS信号屏蔽地区的定位有效性，该方案还提出需要增添类似于EOTD方案中的位测量单元（LMU）。AGPS的具体工作原理如下所示： AGPS手机首先将本身的基站地址通过网络传输到位置服务器； i T?f!D%x?J:T2y?h?y ?b?`?U?T?O&h1VJ Z*B;C 位置服务器根据该手机的大概位置传输与该位置相关的GPS辅助信息（包含GPS的星历和方位俯仰角等）到手机； 该手机的AGPS模块根据辅助信息（以提升GPS信号的第一锁定时间TTFF能力）接收GPS原始信号； 手机在接收到GPS原始信号后解调信号，计算手机到卫星的伪距（伪距为受各种GPS误差影响的距离） ，并将有关信息通过网络传输到位置服位置服务器根据传来的GPS伪距信息和来自其他定位设备（如差分GPS基准站等）的辅助信息完成对GPS信息的处理，并估算该手机的位置；位置服务器将该手机的位置通过网络传输到定位网关或应用平台。 (x s?H7i.Y?E t .^?O?` _ }?D?j AGPS解决方案的优势主要在其定位精度上。在室外等空旷地区，其精度在正常的GPS工作环境下，可达10米左右，堪称目前定位精度最高的一种定位技术。该技术的另一优点为：首次捕获GPS信号的时间一般仅需几秒，不像GPS的首次捕获时间可能要2～3分钟。 虽然AGPS技术的定位精度很高、首次捕获GPS信号时间短，但是该技术也存在着一些缺点。首先，室内定位的问题目前仍然无法圆满解决。另外，AGPS的定位实现必须通过多次网络传输（最多可达六次单向传输），这对运营商来说是被认为大量的占用了空中资源。AGPS最主要的问题是用户对于使用移动定位业务必须更换手机难以接受。而且AGPS手机比一般手机在耗电上有一定的额外负担，间接减短了手机的待机时间。除此之外，就是使用有效性问题。由于GPS系统受美国政府拥有和控制，在非常时期（如海湾战争、反恐战争等），民用GPS服务可能会受到影响，AGPS的定位业务更难以正常运作了。目前，AGPS的方案提供商主要是美国高通公司和其子公司Snaptrack公司，现在还只能用于CDMA和iDEN网络的市场，在不久的将来该定位技术还会用于GSM网络（参见高通公司2002年3月出版的GSM AGPS手机测试移动定位业务报告）。)}?y2X?z?G?k#\?r AGPS不仅由手机利用GPS，还得到蜂窝网络的协助。这是因为网络包括基站和移动交换中心，掌握较多的情况。每当某一移动手机需要定位时，网络可根据它从多个卫星连续观测到的情况告知需要定位的用户，大大地节约用户自己广泛跟踪的过程，并节约用户手机的电池消耗。而且，用户有了这种AGPS提供的情况，又可以提高用户GPS的灵敏度。

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点，圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设，他们都有相同的疑问：一个微服务架构有哪些技术关注点 (technical concerns)？需要哪些基础框架或组件来支持微服务架构？这些框架或组件该如何选型？笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设，同时在这块也投入了很多时间去学习和研究，有一些经验和学习心得，可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同，微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，这时候必然引入一个服务注册发现问题，也就是说服务提供方要注册通告服务地址，服务的调用方要能发现目标服务，同时服务提供方一般以集群方式提供服务，也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同，目前主要的服务注册、发现和负载均衡方案有三种： 第一种是集中式 LB 方案，如下图 Fig 1，在服务消费者和服务提供者之间有一个独立的 LB，LB 通常是专门的硬件设备如 F5，或者基于软件如 LVS，HAproxy 等实现。LB 上有所有服务的地址映射表，通常由运维配置注册，当服务消费方调用某个目标服务时，它向 LB 发起请求，由 LB 以某种策略（比如 Round-Robin）做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力，能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢？通常的做法是通过 DNS，运维人员为服务配置一个 DNS 域名，这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单，在 LB 上也容易做集中式的访问控制，这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题，所有服务调用流量都经过 LB，当服务数量和调用量大的时候，LB 容易成为瓶颈，且一旦 LB 发生故障对整个系统的影响是灾难性的。另外，LB 在服务消费方和服务提供方之间增加了一跳 (hop)，有一定性能开销。 第二种是进程内 LB 方案，针对集中式 LB 的不足，进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头，该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案，下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现，服务提供方启动时，首先将服务地址注册到服务注册表（同时定期报心跳到服务注册表以表明服务的存活状态，相当于健康检查），服务消费方要访问某个服务时，它通过内置的 LB 组件向服务注册表查询（同时缓存并定期刷新）目标服务地址列表，然后以某种负载均衡策略选择一个目标服务地址，最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高，一般采用能满足高可用分布式一致的组件（例如 Zookeeper, Consul, Etcd 等）来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案，LB 和服务发现能力被分散到每一个服务消费者的进程内部，同时服务消费方和服务提供方之间是直接调用，没有额外开销，性能比较好。但是，该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头，如果企业内有多种不同的语言栈，就要配合开发多种不同的客户端，有一定的研发和维护成本。另外，一旦客户端跟随服务调用方发布到生产环境中，后续如果要对客户库进行升级，势必要求服务调用方修改代码并重新发布，所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架，对应的组件分别是：Eureka 服务注册表，Karyon 服务端框架支持服务自注册和健康检查，Ribbon 客户端框架支持服务自发现和软路由。另外，阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案，该方案是针对第二种方案的不足而提出的一种折中方案，原理和第二种方案基本类似，不同之处是，他将 LB 和服务发现功能从进程内移出来，变成主机上的一个独立进程，主机上的一个或者多个服务要访问目标服务时，他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡，见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案，没有单点问题，一个 LB 进程挂了只影响该主机上的服务调用方，服务调用方和 LB 之间是进程内调用，性能好，同时，该方案还简化了服务调用方，不需要为不同语言开发客户库，LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂，环节多，出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架，对应组件分别是：Zookeeper 作为服务注册表，Nerve 独立进程负责服务注册和健康检查，Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes，其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外，最终要以某种方式暴露出去，才能让外界系统（例如客户的浏览器、移动设备等等）访问到，这就涉及服务的前端路由，对应的组件是服务网关 (Service Gateway)，见图 Fig 4，网关是连接企业内部和外部系统的一道门，有如下关键作用： 服务反向路由，网关要负责将外部请求反向路由到内部具体的微服务，这样虽然企业内部是复杂的分布式微服务结构，但是外部系统从网关上看到的就像是一个统一的完整服务，网关屏蔽了后台服务的复杂性，同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫，所有外部请求必须经过网关，网关可以集中对访问进行安全控制，比如用户认证和授权，同时还可以分析访问模式实现防爬虫功能，网关是连接企业内外系统的安全之门。限流和容错，在流量高峰期，网关可以限制流量，保护后台系统不被大流量冲垮，在内部系统出现故障时，网关可以集中做容错，保持外部良好的用户体验。监控，网关可以集中监控访问量，调用延迟，错误计数和访问模式，为后端的性能优化或者扩容提供数据支持。日志，网关可以收集所有的访问日志，进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外，网关还可以实现线上引流，线上压测，线上调试 (Surgical debugging)，金丝雀测试 (Canary Testing)，数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层，有一定的计算逻辑，一般以集群方式部署，前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul，特点是动态可热部署的过滤器 (filter) 机制，其它如 HAproxy，Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后，我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制，该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中，服务简化为两层，后端通用服务（也称中间层服务 Middle Tier Service）和前端服务（也称边缘服务 Edge Service，前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备，如 PC，Pad 或者 Phone）。后端服务启动时会将地址信息注册到服务注册表，前端服务通过查询服务注册表就可以发现然后调用后端服务；前端服务启动时也会将地址信息注册到服务注册表，这样网关通过查询服务注册表就可以将请求路由到目标前端服务，这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看，网关类似 Proxy 代理或者 Façade 门面模式，而服务注册表和服务自注册自发现类似 IoC 依赖注入模式，微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源 (线程，队列等) 被耗尽，造成所谓的雪崩效应 (Cascading Failure，见图 Fig 7)，严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践，业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践，主要包括： Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图，正常状态下，电路处于关闭状态 (Closed)，如果调用持续出错或者超时，电路被打开进入熔断状态 (Open)，后续一段时间内的所有调用都会被拒绝 (Fail Fast)，一段时间以后，保护器会尝试进入半熔断状态 (Half-Open)，允许少量请求进来尝试，如果调用仍然失败，则回到熔断状态，如果调用成功，则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern)，顾名思义，该模式像舱壁一样对资源或失败单元进行隔离，如果一个船舱破了进水，只损失一个船舱，其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子，假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务，且部署 A 的容器一共有 120 个工作线程，采用线程隔离机制，可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程，当 Svc2 慢了，给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽，线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响，如果没有这种隔离机制，当 Svc2 慢的时候，120 个工作线程会很快全部被对 Svc2 的调用吃光，整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder)，服务总有容量限制，没有限流机制的服务很容易在突发流量 (秒杀，双十一) 时被冲垮。限流通常指对服务限定并发访问量，比如单位时间只允许 100 个并发调用，对超过这个限制的请求要拒绝并回退。回退 (fallback)，在熔断或者限流发生的时候，应用程序的后续处理逻辑是什么？回退是系统的弹性恢复能力，常见的处理策略有，直接抛出异常，也称快速失败 (Fail Fast)，也可以返回空值或缺省值，还可以返回备份数据，如果主服务熔断了，可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中，凡是需要容错的依赖点 (服务，缓存，数据库访问等)，开发人员只需要将调用封装在 Hystrix Command 里头，则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证，是 Netflix 微服务平台稳定性和弹性的基石，正逐渐被社区接受为标准容错组件。 服务框架微服务化以后，为了让业务开发人员专注于业务逻辑实现，避免冗余和重复劳动，规范研发提升效率，必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑，包括： Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查，假定采用进程内 LB 方案，那么服务自注册一般统一做在服务器端框架中，健康检查逻辑由具体业务服务定制，框架层提供调用健康检查逻辑的机制，服务发现和负载均衡则集成在服务客户端框架中。监控日志，框架一方面要记录重要的框架层日志、metrics 和调用链数据，还要将日志、metrics 等接口暴露出来，让业务层能根据需要记录业务日志数据。在运行环境中，所有日志数据一般集中落地到企业后台日志系统，做进一步分析和处理。REST/RPC 和序列化，框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来，HTTP/REST 是当前主流 API 暴露方式，在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等)，框架层要支持可定制的序列化机制，例如，对浏览器，框架支持输出 Ajax 友好的 JSON 消息格式，而对无线设备上的 Native App，框架支持输出性能高的 Binary 消息格式。配置，除了支持普通配置文件方式的配置，框架层还可集成动态运行时配置，能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错，框架集成限流容错组件，能够在运行时自动限流和容错，保护服务，如果进一步和动态配置相结合，还可以实现动态限流和熔断。管理接口，框架集成管理接口，一方面可以在线查看框架和服务内部状态，同时还可以动态调整内部状态，对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理，对于框架层和服务的内部异常，如果框架层能够统一处理并记录日志，对服务监控和快速问题定位有很大帮助。安全，安全和访问控制逻辑可以在框架层统一进行封装，可做成插件形式，具体业务服务根据需要加载相关安全插件。文档自动生成，文档的书写和同步一直是一个痛点，框架层如果能支持文档的自动生成和同步，会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon，Spring 的 Spring Boot/Cloud，阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置，例如访问数据库有连接字符串配置，连接池大小和连接超时配置，这些配置在不同环境 (开发 / 测试 / 生产) 一般不同，比如生产环境需要配连接池，而开发测试环境可能不配，另外有些参数配置在运行期可能还要动态调整，例如，运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置，简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上，用户通过管理界面配置和调整服务配置，具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置，拉方式比较可靠，但会有延迟同时有无效网络开销 (假设配置不常更新)，服务器推方式能及时更新配置，但是实现较复杂，一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题，对于大规模服务化环境，配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf，360 的 QConf，Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司，几年前，Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区，这些框架和组件包括： Eureka:　服务注册发现框架Zuul:　服务网关Karyon:　服务端框架Ribbon:　客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系，来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证，正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品，主要是基于对 Netflix 开源组件的进一步封装，方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说，充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud)，在此基础上进行必要的企业定制，无疑是通向微服务架构的捷径。 原文地址：https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C

一 容器 在学习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 这些内容都非常熟练以后，基本就达到了入门的水平。

在开始谈我对架构本质的理解之前，先谈谈对今天技术沙龙主题的个人见解，千万级规模的网站感觉数量级是非常大的，对这个数量级我们战略上 要重 视 它 ， 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级？现在很流行的优步(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、 分布式系 统、数据结构和算法。

密码学简介 据记载，公元前400年，古希腊人发明了置换密码。1881年世界上的第一个电话保密专利出现。在第二次世界大战期间，德国军方启用“恩尼格玛”密码机，密码学在战争中起着非常重要的作用。 随着信息化和数字化社会的发展，人们对信息安全和保密的重要性认识不断提高，于是在1997年，美国国家标准局公布实施 了“美国数据加密标准（DES）”，民间力量开始全面介入密码学的研究和应用中，采用的加密算法有DES、RSA、SHA等。随着对加密强度需求的不断提 高，近期又出现了AES、ECC等。 使用密码学可以达到以下目的： 保密性：防止用户的标识或数据被读取。 数据完整性：防止数据被更改。 身份验证：确保数据发自特定的一方。 二. 加密算法介绍 根据密钥类型不同将现代密码技术分为两类：对称加密算法（秘密钥匙加密）和非对称加密算法（公开密钥加密）。 对称钥匙加密系统是加密和解密均采用同一把秘密钥匙，而且通信双方都必须获得这把钥匙，并保持钥匙的秘密。 非对称密钥加密系统采用的加密钥匙（公钥）和解密钥匙（私钥）是不同的。 对称加密算法 对称加密算法用来对敏感数据等信息进行加密，常用的算法包括： DES（Data Encryption Standard）：数据加密标准，速度较快，适用于加密大量数据的场合。 3DES（Triple DES）：是基于DES，对一块数据用三个不同的密钥进行三次加密，强度更高。 AES（Advanced Encryption Standard）：高级加密标准，是下一代的加密算法标准，速度快，安全级别高； AES 2000年10月，NIST（美国国家标准和技术协会）宣布通过从15种侯选算法中选出的一项新的密匙加密标准。 Rijndael被选中成为将来的AES。 Rijndael是在 1999 年下半年，由研究员 Joan Daemen 和 Vincent Rijmen 创建的。AES 正日益成为加密各种形式的电子数据的实际标准。 美国标准与技术研究院 (NIST) 于 2002 年 5 月 26 日制定了新的高级加密标准 (AES) 规范。 算法原理 AES 算法基于排列和置换运算。排列是对数据重新进行安排，置换是将一个数据单元替换为另一个。AES 使用几种不同的方法来执行排列和置换运算。 AES 是一个迭代的、对称密钥分组的密码，它可以使用128、192 和 256 位密钥，并且用 128 位（16 字节）分组加密和解密数据。与公共密钥密码使用密钥对不同，对称密钥密码使用相同的密钥加密和解密数据。通过分组密码返回的加密数据的位数与输入数据相 同。迭代加密使用一个循环结构，在该循环中重复置换和替换输入数据 AES与3DES的比较 算法名称 算法类型 密钥长度 速度 解密时间（建设机器每秒尝试255个密钥） 资源消耗 AES 对称block密码 128、192、256位 高 1490000亿年 低 3DES 对称feistel密码 112位或168位 低 46亿年 中 非对称算法 常见的非对称加密算法如下： RSA：由 RSA 公司发明，是一个支持变长密钥的公共密钥算法，需要加密的文件块的长度也是可变的； DSA（Digital Signature Algorithm）：数字签名算法，是一种标准的 DSS（数字签名标准）； ECC（Elliptic Curves Cryptography）：椭圆曲线密码编码学。 ECC 在1976年，由于对称加密算法已经不能满足需要，Diffie 和Hellman发表了一篇叫《密码学新动向》的文章，介绍了公匙加密的概念，由Rivet、Shamir、Adelman提出了RSA算法。 随着分解大整数方法的进步及完善、计算机速度的提高以及计算机网络的发展，为了保障数据的安全，RSA的密钥需要不断增 加，但是，密钥长度的增加导致了其加解密的速度大为降低，硬件实现也变得越来越难以忍受，这对使用RSA的应用带来了很重的负担，因此需要一种新的算法来 代替RSA。 1985年N.Koblitz和Miller提出将椭圆曲线用于密码算法，根据是有限域上的椭圆曲线上的点群中的离散对数问题ECDLP。ECDLP是比因子分解问题更难的问题，它是指数级的难度。 算法原理——椭圆曲线上的难题 椭圆曲线上离散对数问题ECDLP定义如下：给定素数p和椭圆曲线E，对Q＝kP，在已知P，Q 的情况下求出小于p的正整数k。可以证明由k和P计算Q比较容易，而由Q和P计算k则比较困难。 将椭圆曲线中的加法运算与离散对数中的模乘运算相对应，将椭圆曲线中的乘法运算与离散对数中的模幂运算相对应，我们就可以建立基于椭圆曲线的对应的密码体制。 例如，对应Diffie-Hellman公钥系统，我们可以通过如下方式在椭圆曲线上予以实现：在E上选取生成元P，要 求由P产生的群元素足够多，通信双方A和B分别选取a和b，a和b 予以保密，但将aP和bP公开，A和B间通信用的密钥为abP，这是第三者无法得知 的。 对应ELGamal密码系统可以采用如下的方式在椭圆曲线上予以实现： 将明文m嵌入到E上Pm点，选一点B∈E，每一用户都选一整数a，0＜a＜N，N为阶数已知，a保密，aB公开。欲向A 送m，可送去下面一对数偶：［kB，Pm+k(aAB)］，k是随机产生的整数。A可以从kB求得k(aAB)。通过：Pm+k(aAB)- k(aAB)=Pm恢复Pm。同样对应DSA，考虑如下等式： K=kG [其中 K，G为Ep(a,b)上的点，k为小于n（n是点G的阶）的整数] 不难发现，给定k和G，根据加法法则，计算K很容易；但给定K和G，求k就相对困难了。 这就是椭圆曲线加密算法采用的难题。我们把点G称为基点（base point），k（k<n，n为基点G的阶）称为私有密钥（privte key），K称为公开密钥（public key)。 ECC与RSA的比较 ECC和RSA相比，在许多方面都有对绝对的优势，主要体现在以下方面： Ø 抗攻击性强。相同的密钥长度，其抗攻击性要强很多倍。 Ø 计算量小，处理速度快。ECC总的速度比RSA、DSA要快得多。 Ø 存储空间占用小。ECC的密钥尺寸和系统参数与RSA、DSA相比要小得多，意味着它所占的存贮空间要小得多。这对于加密算法在IC卡上的应用具有特别重要的意义。 Ø 带宽要求低。当对长消息进行加解密时，三类密码系统有相同的带宽要求，但应用于短消息时ECC带宽要求却低得多。带宽要求低使ECC在无线网络领域具有广泛的应用前景。 ECC的这些特点使它必将取代RSA，成为通用的公钥加密算法。比如SET协议的制定者已把它作为下一代SET协议中缺省的公钥密码算法。 下面两张表示是RSA和ECC的安全性和速度的比较： 攻破时间 (MIPS年) RSA/DSA (密钥长度) ECC 密钥长度 RSA/ECC 密钥长度比 104 512 106 5：1 108 768 132 6：1 1011 1024 160 7：1 1020 2048 210 10：1 1078 21000 600 35：1 RSA和ECC安全模长得比较 功能 Security Builder 1.2 BSAFE 3.0 163位ECC(ms) 1,023位RSA(ms) 密钥对生成 3.8 4,708.3 签名 2.1(ECNRA) 228.4 3.0(ECDSA) 认证 9.9(ECNRA) 12.7 10.7(ECDSA) Diffie—Hellman密钥交换 7.3 1,654.0 RSA和ECC速度比较 散列算法 散列是信息的提炼，通常其长度要比信息小得多，且为一个固定长度。加密性强的散列一定是不可逆的，这就意味着通过散列结 果，无法推出任何部分的原始信息。任何输入信息的变化，哪怕仅一位，都将导致散列结果的明显变化，这称之为雪崩效应。散列还应该是防冲突的，即找不出具有 相同散列结果的两条信息。具有这些特性的散列结果就可以用于验证信息是否被修改。 单向散列函数一般用于产生消息摘要，密钥加密等，常见的有： Ø MD5（Message Digest Algorithm 5）：是RSA数据安全公司开发的一种单向散列算法。 Ø SHA（Secure Hash Algorithm）：可以对任意长度的数据运算生成一个160位的数值； SHA-1 在1993年，安全散列算法（SHA）由美国国家标准和技术协会(NIST)提出，并作为联邦信息处理标准（FIPS PUB 180）公布；1995年又发布了一个修订版FIPS PUB 180-1，通常称之为SHA-1。SHA-1是基于MD4算法的，并且它的设计在很大程度上是模仿MD4的。现在已成为公认的最安全的散列算法之一，并 被广泛使用。 算法原理 SHA-1是一种数据加密算法，该算法的思想是接收一段明文，然后以一种不可逆的方式将它转换成一段（通常更小）密文，也可以简单的理解为取一串输入码（称为预映射或信息），并把它们转化为长度较短、位数固定的输出序列即散列值（也称为信息摘要或信息认证代码）的过程。 单向散列函数的安全性在于其产生散列值的操作过程具有较强的单向性。如果在输入序列中嵌入密码，那么任何人在不知道密码 的情况下都不能产生正确的散列值，从而保证了其安全性。SHA将输入流按照每块512位（64个字节）进行分块，并产生20个字节的被称为信息认证代码或 信息摘要的输出。 该算法输入报文的最大长度不超过264位，产生的输出是一个160位的报文摘要。输入是按512 位的分组进行处理的。SHA-1是不可逆的、防冲突，并具有良好的雪崩效应。 通过散列算法可实现数字签名实现，数字签名的原理是将要传送的明文通过一种函数运算（Hash）转换成报文摘要（不同的 明文对应不同的报文摘要），报文摘要加密后与明文一起传送给接受方，接受方将接受的明文产生新的报文摘要与发送方的发来报文摘要解密比较，比较结果一致表 示明文未被改动，如果不一致表示明文已被篡改。 MAC (信息认证代码)就是一个散列结果，其中部分输入信息是密码，只有知道这个密码的参与者才能再次计算和验证MAC码的合法性。MAC的产生参见下图。 输入信息 密码 散列函数 信息认证代码 SHA-1与MD5的比较 因为二者均由MD4导出，SHA-1和MD5彼此很相似。相应的，他们的强度和其他特性也是相似，但还有以下几点不同： Ø 对强行供给的安全性：最显著和最重要的区别是SHA-1摘要比MD5摘要长32 位。使用强行技术，产生任何一个报文使其摘要等于给定报摘要的难度对MD5是2128数量级的操作，而对SHA-1则是2160数量级的操作。这样，SHA-1对强行攻击有更大的强度。 Ø 对密码分析的安全性：由于MD5的设计，易受密码分析的攻击，SHA-1显得不易受这样的攻击。 Ø 速度：在相同的硬件上，SHA-1的运行速度比MD5慢。 对称与非对称算法比较 以上综述了两种加密方法的原理，总体来说主要有下面几个方面的不同： Ø 在管理方面：公钥密码算法只需要较少的资源就可以实现目的，在密钥的分配上，两者之间相差一个指数级别（一个是n一个是n2）。所以私钥密码算法不适应广域网的使用，而且更重要的一点是它不支持数字签名。 Ø 在安全方面：由于公钥密码算法基于未解决的数学难题，在破解上几乎不可能。对于私钥密码算法，到了AES虽说从理论来说是不可能破解的，但从计算机的发展角度来看。公钥更具有优越性。 Ø 从速度上来看：AES的软件实现速度已经达到了每秒数兆或数十兆比特。是公钥的100倍，如果用硬件来实现的话这个比值将扩大到1000倍。 三. 加密算法的选择 前面的章节已经介绍了对称解密算法和非对称加密算法，有很多人疑惑：那我们在实际使用的过程中究竟该使用哪一种比较好呢。 我们应该根据自己的使用特点来确定，由于非对称加密算法的运行速度比对称加密算法的速度慢很多，当我们需要加密大量的数据时，建议采用对称加密算法，提高加解密速度。 对称加密算法不能实现签名，因此签名只能非对称算法。 由于对称加密算法的密钥管理是一个复杂的过程，密钥的管理直接决定着他的安全性，因此当数据量很小时，我们可以考虑采用非对称加密算法。 在实际的操作过程中，我们通常采用的方式是：采用非对称加密算法管理对称算法的密钥，然后用对称加密算法加密数据，这样我们就集成了两类加密算法的优点，既实现了加密速度快的优点，又实现了安全方便管理密钥的优点。 如果在选定了加密算法后，那采用多少位的密钥呢。一般来说，密钥越长，运行的速度就越慢，应该根据的我们实际需要的安全级别来选择，一般来说，RSA建议采用1024位的数字，ECC建议采用160位，AES采用128为即可。 四. 密码学在现代的应用 随着密码学商业应用的普及，公钥密码学受到前所未有的重视。除传统的密码应用系统外，PKI系统以公钥密码技术为主，提供加密、签名、认证、密钥管理、分配等功能。 保密通信：保密通信是密码学产生的动因。使用公私钥密码体制进行保密通信时，信息接收者只有知道对应的密钥才可以解密该信息。 数字签名：数字签名技术可以代替传统的手写签名，而且从安全的角度考虑，数字签名具有很好的防伪造功能。在政府机关、军事领域、商业领域有广泛的应用环境。 秘密共享：秘密共享技术是指将一个秘密信息利用密码技术分拆成n个称为共享因子的信息，分发给n个成员，只有 k(k≤n)个合法成员的共享因子才可以恢复该秘密信息，其中任何一个或m(m≤k)个成员合作都不知道该秘密信息。利用秘密共享技术可以控制任何需要多 个人共同控制的秘密信息、命令等。 认证功能：在公开的信道上进行敏感信息的传输，采用签名技术实现对消息的真实性、完整性进行验证，通过验证公钥证书实现对通信主体的身份验证。 密钥管理：密钥是保密系统中更为脆弱而重要的环节，公钥密码体制是解决密钥管理工作的有力工具；利用公钥密码体制进行密钥协商和产生，保密通信双方不需要事先共享秘密信息；利用公钥密码体制进行密钥分发、保护、密钥托管、密钥恢复等。 基于公钥密码体制可以实现以上通用功能以外，还可以设计实现以下的系统：安全电子商务系统、电子现金系统、电子选举系统、电子招投标系统、电子彩票系统等。 公钥密码体制的产生是密码学由传统的政府、军事等应用领域走向商用、民用的基础，同时互联网、电子商务的发展为密码学的发展开辟了更为广阔的前景。 五. 加密算法的未来 随着计算方法的改进，计算机运行速度的加快，网络的发展，越来越多的算法被破解。 在2004年国际密码学会议(Crypto’2004)上，来自中国山东大学的王小云教授做的破译MD5、HAVAL-128、MD4和RIPEMD算法的报告，令在场的国际顶尖密码学专家都为之震惊，意味着这些算法将从应用中淘汰。随后，SHA-1也被宣告被破解。 历史上有三次对DES有影响的攻击实验。1997年，利用当时各国 7万台计算机，历时96天破解了DES的密钥。1998年，电子边境基金会 （EFF）用25万美元制造的专用计算机，用56小时破解了DES的密钥。1999年，EFF用22小时15分完成了破解工作。因此。曾经有过卓越贡献的 DES也不能满足我们日益增长的需求了。 最近，一组研究人员成功的把一个512位的整数分解因子，宣告了RSA的破解。 我们说数据的安全是相对的，可以说在一定时期一定条件下是安全的，随着硬件和网络的发展，或者是另一个王小云的出现，目前的常用加密算法都有可能在 短时间内被破解，那时我们不得不使用更长的密钥或更加先进的算法，才能保证数据的安全，因此加密算法依然需要不断发展和完善，提供更高的加密安全强度和运 算速度。 纵观这两种算法一个从DES到3DES再到AES，一个从RSA到ECC。其发展角度无不是从密钥的简单性，成本的低廉性，管理的简易性，算法的复 杂性，保密的安全性以及计算的快速性这几个方面去考虑。因此，未来算法的发展也必定是从这几个角度出发的，而且在实际操作中往往把这两种算法结合起来，也 需将来一种集两种算法优点于一身的新型算法将会出现，到那个时候，电子商务的实现必将更加的快捷和安全。

1.阻塞与同步2.BIO与NIO对比3.NIO简介4.缓冲区Buffer5.通道Channel6.反应堆7.选择器8.NIO源码分析9.AIO1.阻塞与同步1）阻塞(Block)和非租塞(NonBlock):阻塞和非阻塞是进程在访问数据的时候，数据是否准备就绪的一种处理方式，当数据没有准备的时候阻塞：往往需要等待缞冲区中的数据准备好过后才处理其他的事情，否則一直等待在那里。非阻塞：当我们的进程访问我们的数据缓冲区的时候，如果数据没有准备好则直接返回，不会等待。如果数据已经准备好，也直接返回2）同步(Synchronization)和异步(Async)的方式：同步和异步都是基于应用程序私操作系统处理IO事件所采用的方式，比如同步：是应用程序要直接参与IO读写的操作。异步：所有的IO读写交给搡作系统去处理，应用程序只需要等待通知。同步方式在处理IO事件的时候，必须阻塞在某个方法上靣等待我们的IO事件完成(阻塞IO事件或者通过轮询IO事件的方式）.对于异步来说，所有的IO读写都交给了搡作系统。这个时候，我们可以去做其他的事情，并不拓要去完成真正的IO搡作，当搡作完成IO后.会给我们的应用程序一个通知同步：阻塞到IO事件，阻塞到read成则write。这个时候我们就完全不能做自己的事情，让读写方法加入到线程里面，然后阻塞线程来实现，对线程的性能开销比较大，参考：https://blog.csdn.net/CharJay_Lin/article/details/812598802.BIO与NIO对比block IO与Non-block IO1）区别IO模型 IO NIO方式 从硬盘到内存 从内存到硬盘通信 面向流（乡村公路） 面向缓存（高速公路，多路复用技术）处理 阻塞IO（多线程） 非阻塞IO（反应堆Reactor）触发 无 选择器（轮询机制）2）面向流与面向缓冲Java NIO和IO之间第一个最大的区别是，IO是面向流的.NIO是面向缓冲区的。Java IO面向流意味着毎次从流中读一个成多个字节，直至读取所有字节，它们没有被缓存在任何地方，此外，它不能前后移动流中的数据。如果需要前后移动从流中读取的教据，需要先将它缓存到一个缓冲区。Java NIO的缓冲导向方法略有不同。数据读取到一个它稍后处理的缓冲区，霱要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是，还需要检查是否该缓冲区中包含所有您需要处理的数裾。而且，需确保当更多的数据读入缓冲区时，不要覆盖缓冲区里尚未处理的数据。3）阻塞与非阻塞Java IO的各种流是阻塞的。这意味着，当一个线程调用read() 或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了。 Java NIO的非阻塞模式，使一个线程从某通道发送请求读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取。而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。 非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。 线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作，所以一个单独的线程现在可以管理多个输入和输出通道（channel）。4）选择器（Selector)Java NIO的选择器允许一个单独的线程来监视多个输入通道，你可以注册多个通道使用一个选择器，然后使用一个单独的线程来“选择"通道：这些通里已经有可以处理的褕入，或者选择已准备写入的通道。这选怿机制，使得一个单独的线程很容易来管理多个通道。5）NIO和BIO读取文件BIO读取文件：链接BIO从一个阻塞的流中一行一行的读取数据image | left | 469x426NIO读取文件：链接通道是数据的载体，buffer是存储数据的地方，线程每次从buffer检查数据通知给通道image | left | 559x3946）处理数据的线程数NIO：一个线程管理多个连接BIO：一个线程管理一个连接3.NIO简介在Java1.4之前的I/O系统中，提供的都是面向流的I/O系统，系统一次一个字节地处理数据，一个输入流产生一个字节的数据，一个输出流消费一个字节的数据，面向流的I/O速度非常慢，而在Java 1.4中推出了NIO，这是一个面向块的I/O系统，系统以块的方式处理处理，每一个操作在一步中产生或者消费一个数据库，按块处理要比按字节处理数据快的多。在NIO中有几个核心对象需要掌握：缓冲区（Buffer）、通道（Channel）、选择器（Selector）。参考：链接image2.png | center | 851x3834.缓冲区Buffer缓冲区实际上是一个容器对象，更直接的说，其实就是一个数组，在NIO库中，所有数据都是用缓冲区处理的。在读取数据时，它是直接读到缓冲区中的； 在写入数据时，它也是写入到缓冲区中的；任何时候访问 NIO 中的数据，都是将它放到缓冲区中。而在面向流I/O系统中，所有数据都是直接写入或者直接将数据读取到Stream对象中。在NIO中，所有的缓冲区类型都继承于抽象类Buffer，最常用的就是ByteBuffer，对于Java中的基本类型，基本都有一个具体Buffer类型与之相对应，它们之间的继承关系如下图所示：image3.png | center | 650x3681）其中的四个属性的含义分别如下：容量（Capacity）：缓冲区能够容纳的数据元素的最大数量。这一个容量在缓冲区创建时被设定，并且永远不能改变。上界(Limit)：缓冲区的第一个不能被读或写的元素。或者说,缓冲区中现存元素的计数。位置(Position)：下一个要被读或写的元素的索引。位置会自动由相应的 get( )和 put( )函数更新。标记(Mark)：下一个要被读或写的元素的索引。位置会自动由相应的 get( )和 put( )函数更新。2）Buffer的常见方法如下所示:flip(): 写模式转换成读模式rewind()：将 position 重置为 0 ，一般用于重复读。clear() ：compact(): 将未读取的数据拷贝到 buffer 的头部位。mark(): reset():mark 可以标记一个位置， reset 可以重置到该位置。Buffer 常见类型： ByteBuffer 、 MappedByteBuffer 、 CharBuffer 、 DoubleBuffer 、 FloatBuffer 、 IntBuffer 、 LongBuffer 、 ShortBuffer 。3）基本操作Buffer基础操作： 链接缓冲区分片，缓冲区分配，直接缓存区，缓存区映射，缓存区只读：链接4）缓冲区存取数据流程存数据时position会++，当停止数据读取的时候调用flip()，此时limit=position，position=0读取数据时position++，一直读取到limitclear() 清空 buffer ，准备再次被写入 (position 变成 0 ， limit 变成 capacity) 。5.通道Channel通道是一个对象，通过它可以读取和写入数据，当然了所有数据都通过Buffer对象来处理。我们永远不会将字节直接写入通道中，相反是将数据写入包含一个或者多个字节的缓冲区。同样不会直接从通道中读取字节，而是将数据从通道读入缓冲区，再从缓冲区获取这个字节。image4.png | center | 368x191在NIO中，提供了多种通道对象，而所有的通道对象都实现了Channel接口。它们之间的继承关系如下图所示：image5.png | center | 650x5171）使用NIO读取数据在前面我们说过，任何时候读取数据，都不是直接从通道读取，而是从通道读取到缓冲区。所以使用NIO读取数据可以分为下面三个步骤：从FileInputStream获取Channel 创建Buffer 将数据从Channel读取到Buffer中 例子：链接 2）使用NIO写入数据使用NIO写入数据与读取数据的过程类似，同样数据不是直接写入通道，而是写入缓冲区，可以分为下面三个步骤：从FileInputStream获取Channel 创建Buffer 将数据从Channel写入到Buffer中 例子：链接 6.反应堆1）阻塞IO模型在老的IO包中，serverSocket和socket都是阻塞式的，因此一旦有大规模的并发行为，而每一个访问都会开启一个新线程。这时会有大规模的线程上下文切换操作（因为都在等待，所以资源全都被已有的线程吃掉了），这时无论是等待的线程还是正在处理的线程，响应率都会下降，并且会影响新的线程。image6.png | center | 739x3362）NIOJava NIO是在jdk1.4开始使用的，它既可以说成“新IO”，也可以说成非阻塞式I/O。下面是java NIO的工作原理：1.由一个专门的线程来处理所有的IO事件，并负责分发。2.事件驱动机制：事件到的时候触发，而不是同步的去监视事件。3.线程通讯：线程之间通过wait,notify等方式通讯。保证每次上下文切换都是有意义的。减少无谓的线程切换。image7.png | center | 689x251注：每个线程的处理流程大概都是读取数据，解码，计算处理，编码，发送响应。7.选择器传统的 server / client 模式会基于 TPR ( Thread per Request ) ．服务器会为每个客户端请求建立一个线程．由该线程单独负贵处理一个客户请求。这种模式带未的一个问题就是线程数是的剧增．大量的线程会增大服务器的开销，大多数的实现为了避免这个问题，都采用了线程池模型，并设置线程池线程的最大数量，这又带来了新的问题，如果线程池中有 200 个线程，而有 200 个用户都在进行大文件下载，会导致第 201 个用户的请求无法及时处理，即便第 201 个用户只想请求一个几 KB 大小的页面。传统的 Sorvor / Client 模式如下围所示：image8.png | center | 597x286NIO 中非阻塞IO采用了基于Reactor模式的工作方式，IO调用不会被阻塞，相反是注册感兴趣的特点IO事件，如可读数据到达，新的套接字等等，在发生持定率件时，系统再通知我们。 NlO中实现非阻塞IO的核心设计Selector，Selector就是注册各种IO事件的地方，而且当那些事件发生时，就是这个对象告诉我们所发生的事件。image9.png | center | 462x408当有读或者写等任何注册的事件发生时，可以从Selector中获得相应的SelectionKey，同时从SelectionKey中可以找到发生的事件和该事件所发生的具体的SelectableChannel，以获得客户端发送过来的数据。使用NIO中非阻塞IO编写服务器处理程序，有三个步骤1.向Selector对象注册感兴趣的事件2.从Selector中获取感兴趣的事件3.根据不同事件进行相应的处理8.NIO源码分析Selector是NIO的核心epool模型1）SelectorSelector的open()方法：链接2）ServerSocketChannelServerSocketChannel.open() 链接9.AIOAsynchronous IO异步非阻塞IOBIO ServerSocketNIO ServerSocketChannelAIO AsynchronousServerSocketChannel

你这是几年工作经验（多少钱的岗位）问到这些问题的？ Q1：如果对时效性要求不是太高的话，首先考虑静态化。静态资源请求处理耗系统资源少，不会请求数据库。数据库方面可以加个缓存，或者查询频率高的直接全部放redis。（再接着问的话再接着往深里回答） Q2:数据库性能问题？这题太抽象，反问一句具体场景，再具体问题具体分析。这块我也不熟。但是数据库一般就分表、表分区、分库、索引。 Q3:简单的实现可以是 nginx用upstream做负载（apache同样可以），静态资源直接urlrewrite到专门服务器上，对后端请求通过upstream配置分发到不同服务器上，这里主要做一些session复制或者自己实现一套无session的用户跟踪机制。或者更复杂的，在第一个server前搞个lvs。原理主要就是多服务器处理请求。其实负载这些都是专业的运维搞更好，术业有专攻。并且小公司的项目并发也不会高到哪里去，真高了也就有钱找专业的运维了。 ######我才两年多，回答的不错，赞！###### Q1就是扯淡，没有具体场景，方案完全不一样。 ######回答这种题目也没什么扯淡的吧，主要还是考你知不知道这方面的知识。你可以在交流过程中自己把场景限定下来，然后给出解决方案的思路，这种问题没有标准答案，面试官也会根据你的回答来深入探讨，看面试者的水平在什么level。###### 现在企业数据量庞大，应用越来越普及 所以性能问题很明显，重要性比较突出 ###### 现在普通的笔记本都安装64位，内存好大 不做集群自己试试那就等于浪费 ######不排除有的公司是为了拿这个来考验你的实力！也不排除它这个公司就有那么大的数据流量。######可以参考一下我的博客关于系统调优的###### 哈，我给楼主正确答案吧。问你问题的，最近正在考虑这些，而且自己琢磨出来一套方案了，想看看是否有共鸣，或者让别人说些更sb的方案好bs一下，然后乐乐，别无其他，答的有点上路子，但被bs，是最佳状态。如果你一不小心，呼呼呼，顺着他的思路，说了很多他暂时还没想到的，基本他会10分钟内容去找技术总监“来了个狠的，招架不住，大哥，帮一把吧。。。” 如果你遇到这种情况，就是技术总监，过了5分钟慢悠悠的来了，一般他不会如pm那样问直接问题，而是随意聊聊，大体套路就是”刚才我同事已经和你交流了不少，你的水平很不错“云云。随后会尽可能了解你的整体情况后，再下手做技术对答。 不过面试时，能把pm说晕，让技术总监出来的，基本上也就大家交个朋友了，因为暂需岗位和你的人力已经不匹配了。。就当喝下午茶。这种事情我干过。 补充说一点，pm这个级别出来面试，一般都会从自己的视角面来谈技术。所以通常会问自己正在琢磨的问题。你就是提出一个足以否定他们的更好多方案也不会改变他们已经实施的计划。 ######我顶######我刚毕业1年，也问我这些。问我集群，问我给数据库优化，问我hadoop###### 引用来自“张子游”的答案 我刚毕业1年，也问我这些。问我集群，问我给数据库优化，问我hadoop 确实，现在不少公司对应届生也问这样的问题(比如某刚被百度收购的p2p视频公司) ######我觉得就是看你有多少招数来应对这些问题，不能一点都没有啊，等真遇到这问题了你搞不定就麻烦了。

服务器和操作系统 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流水线实现

Kafka 是目前主流的分布式消息引擎及流处理平台，经常用做企业的消息总线、实时数据管道，本文挑选了 Kafka 的几个核心话题，帮助大家快速掌握 Kafka，包括： Kafka 体系架构 Kafka 消息发送机制 Kafka 副本机制 Kafka 控制器 Kafka Rebalance 机制 因为涉及内容较多，本文尽量做到深入浅出，全面的介绍 Kafka 原理及核心组件，不怕你不懂 Kafka。 1. Kafka 快速入门 Kafka 是一个分布式消息引擎与流处理平台，经常用做企业的消息总线、实时数据管道，有的还把它当做存储系统来使用。早期 Kafka 的定位是一个高吞吐的分布式消息系统，目前则演变成了一个成熟的分布式消息引擎，以及流处理平台。 1.1 Kafka 体系架构 Kafka 的设计遵循生产者消费者模式，生产者发送消息到 broker 中某一个 topic 的具体分区里，消费者从一个或多个分区中拉取数据进行消费。拓扑图如下： 目前，Kafka 依靠 Zookeeper 做分布式协调服务，负责存储和管理 Kafka 集群中的元数据信息，包括集群中的 broker 信息、topic 信息、topic 的分区与副本信息等。 ** 1.2 Kafka 术语** 这里整理了 Kafka 的一些关键术语： Producer：生产者，消息产生和发送端。 Broker：Kafka 实例，多个 broker 组成一个 Kafka 集群，通常一台机器部署一个 Kafka 实例，一个实例挂了不影响其他实例。 Consumer：消费者，拉取消息进行消费。 一个 topic 可以让若干个消费者进行消费，若干个消费者组成一个 Consumer Group 即消费组，一条消息只能被消费组中一个 Consumer 消费。 Topic：主题，服务端消息的逻辑存储单元。一个 topic 通常包含若干个 Partition 分区。 Partition：topic 的分区，分布式存储在各个 broker 中， 实现发布与订阅的负载均衡。若干个分区可以被若干个 Consumer 同时消费，达到消费者高吞吐量。一个分区拥有多个副本（Replica），这是Kafka在可靠性和可用性方面的设计，后面会重点介绍。 message：消息，或称日志消息，是 Kafka 服务端实际存储的数据，每一条消息都由一个 key、一个 value 以及消息时间戳 timestamp 组成。 offset：偏移量，分区中的消息位置，由 Kafka 自身维护，Consumer 消费时也要保存一份 offset 以维护消费过的消息位置。 1.3 Kafka 作用与特点 Kafka 主要起到削峰填谷（缓冲）、系统解构以及冗余的作用，主要特点有： 高吞吐、低延时：这是 Kafka 显著的特点，Kafka 能够达到百万级的消息吞吐量，延迟可达毫秒级； 持久化存储：Kafka 的消息最终持久化保存在磁盘之上，提供了顺序读写以保证性能，并且通过 Kafka 的副本机制提高了数据可靠性。 分布式可扩展：Kafka 的数据是分布式存储在不同 broker 节点的，以 topic 组织数据并且按 partition 进行分布式存储，整体的扩展性都非常好。 高容错性：集群中任意一个 broker 节点宕机，Kafka 仍能对外提供服务。 2. Kafka 消息发送机制 Kafka 生产端发送消息的机制非常重要，这也是 Kafka 高吞吐的基础，生产端的基本流程如下图所示： 主要有以下方面的设计： 2.1 异步发送 Kafka 自从 0.8.2 版本就引入了新版本 Producer API，新版 Producer 完全是采用异步方式发送消息。生产端构建的 ProducerRecord 先是经过 keySerializer、valueSerializer 序列化后，再是经过 Partition 分区器处理，决定消息落到 topic 具体某个分区中，最后把消息发送到客户端的消息缓冲池 accumulator 中，交由一个叫作 Sender 的线程发送到 broker 端。 这里缓冲池 accumulator 的最大大小由参数 buffer.memory 控制，默认是 32M，当生产消息的速度过快导致 buffer 满了的时候，将阻塞 max.block.ms 时间，超时抛异常，所以 buffer 的大小可以根据实际的业务情况进行适当调整。 2.2 批量发送 发送到缓冲 buffer 中消息将会被分为一个一个的 batch，分批次的发送到 broker 端，批次大小由参数 batch.size 控制，默认16KB。这就意味着正常情况下消息会攒够 16KB 时才会批量发送到 broker 端，所以一般减小 batch 大小有利于降低消息延时，增加 batch 大小有利于提升吞吐量。 那么生成端消息是不是必须要达到一个 batch 大小时，才会批量发送到服务端呢？答案是否定的，Kafka 生产端提供了另一个重要参数 linger.ms，该参数控制了 batch 最大的空闲时间，超过该时间的 batch 也会被发送到 broker 端。 2.3 消息重试 此外，Kafka 生产端支持重试机制，对于某些原因导致消息发送失败的，比如网络抖动，开启重试后 Producer 会尝试再次发送消息。该功能由参数 retries 控制，参数含义代表重试次数，默认值为 0 表示不重试，建议设置大于 0 比如 3。 3. Kafka 副本机制 前面提及了 Kafka 分区副本（Replica）的概念，副本机制也称 Replication 机制是 Kafka 实现高可靠、高可用的基础。Kafka 中有 leader 和 follower 两类副本。 3.1 Kafka 副本作用 Kafka 默认只会给分区设置一个副本，由 broker 端参数 default.replication.factor 控制，默认值为 1，通常我们会修改该默认值，或者命令行创建 topic 时指定 replication-factor 参数，生产建议设置 3 副本。副本作用主要有两方面： 消息冗余存储，提高 Kafka 数据的可靠性； 提高 Kafka 服务的可用性，follower 副本能够在 leader 副本挂掉或者 broker 宕机的时候参与 leader 选举，继续对外提供读写服务。 3.2 关于读写分离 这里要说明的是 Kafka 并不支持读写分区，生产消费端所有的读写请求都是由 leader 副本处理的，follower 副本的主要工作就是从 leader 副本处异步拉取消息，进行消息数据的同步，并不对外提供读写服务。 Kafka 之所以这样设计，主要是为了保证读写一致性，因为副本同步是一个异步的过程，如果当 follower 副本还没完全和 leader 同步时，从 follower 副本读取数据可能会读不到最新的消息。 3.3 ISR 副本集合 Kafka 为了维护分区副本的同步，引入 ISR（In-Sync Replicas）副本集合的概念，ISR 是分区中正在与 leader 副本进行同步的 replica 列表，且必定包含 leader 副本。 ISR 列表是持久化在 Zookeeper 中的，任何在 ISR 列表中的副本都有资格参与 leader 选举。 ISR 列表是动态变化的，并不是所有的分区副本都在 ISR 列表中，哪些副本会被包含在 ISR 列表中呢？副本被包含在 ISR 列表中的条件是由参数 replica.lag.time.max.ms 控制的，参数含义是副本同步落后于 leader 的最大时间间隔，默认10s，意思就是说如果某一 follower 副本中的消息比 leader 延时超过10s，就会被从 ISR 中排除。Kafka 之所以这样设计，主要是为了减少消息丢失，只有与 leader 副本进行实时同步的 follower 副本才有资格参与 leader 选举，这里指相对实时。 3.4 Unclean leader 选举 既然 ISR 是动态变化的，所以 ISR 列表就有为空的时候，ISR 为空说明 leader 副本也“挂掉”了，此时 Kafka 就要重新选举出新的 leader。但 ISR 为空，怎么进行 leader 选举呢？ Kafka 把不在 ISR 列表中的存活副本称为“非同步副本”，这些副本中的消息远远落后于 leader，如果选举这种副本作为 leader 的话就可能造成数据丢失。Kafka broker 端提供了一个参数 unclean.leader.election.enable，用于控制是否允许非同步副本参与 leader 选举；如果开启，则当 ISR 为空时就会从这些副本中选举新的 leader，这个过程称为 Unclean leader 选举。 前面也提及了，如果开启 Unclean leader 选举，可能会造成数据丢失，但保证了始终有一个 leader 副本对外提供服务；如果禁用 Unclean leader 选举，就会避免数据丢失，但这时分区就会不可用。这就是典型的 CAP 理论，即一个系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两个。所以在这个问题上，Kafka 赋予了我们选择 C 或 A 的权利。 我们可以根据实际的业务场景选择是否开启 Unclean leader选举，这里建议关闭 Unclean leader 选举，因为通常数据的一致性要比可用性重要的多。 4. Kafka 控制器 控制器（Controller）是 Kafka 的核心组件，它的主要作用是在 Zookeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一个 broker 都能充当控制器的角色，但在运行过程中，只能有一个 broker 成为控制器。 这里先介绍下 Zookeeper，因为控制器的产生依赖于 Zookeeper 的 ZNode 模型和 Watcher 机制。Zookeeper 的数据模型是类似 Unix 操作系统的 ZNode Tree 即 ZNode 树，ZNode 是 Zookeeper 中的数据节点，是 Zookeeper 存储数据的最小单元，每个 ZNode 可以保存数据，也可以挂载子节点，根节点是 /。基本的拓扑图如下： Zookeeper 有两类 ZNode 节点，分别是持久性节点和临时节点。持久性节点是指客户端与 Zookeeper 断开会话后，该节点依旧存在，直到执行删除操作才会清除节点。临时节点的生命周期是和客户端的会话绑定在一起，客户端与 Zookeeper 断开会话后，临时节点就会被自动删除。 Watcher 机制是 Zookeeper 非常重要的特性，它可以在 ZNode 节点上绑定监听事件，比如可以监听节点数据变更、节点删除、子节点状态变更等事件，通过这个事件机制，可以基于 ZooKeeper 实现分布式锁、集群管理等功能。 4.1 控制器选举 当集群中的任意 broker 启动时，都会尝试去 Zookeeper 中创建 /controller 节点，第一个成功创建 /controller 节点的 broker 则会被指定为控制器，其他 broker 则会监听该节点的变化。当运行中的控制器突然宕机或意外终止时，其他 broker 能够快速地感知到，然后再次尝试创建 /controller 节点，创建成功的 broker 会成为新的控制器。 4.2 控制器功能 前面我们也说了，控制器主要作用是管理和协调 Kafka 集群，那么 Kafka 控制器都做了哪些事情呢，具体如下： 主题管理：创建、删除 topic，以及增加 topic 分区等操作都是由控制器执行。 分区重分配：执行 Kafka 的 reassign 脚本对 topic 分区重分配的操作，也是由控制器实现。 Preferred leader 选举：这里有一个概念叫 Preferred replica 即优先副本，表示的是分配副本中的第一个副本。Preferred leader 选举就是指 Kafka 在某些情况下出现 leader 负载不均衡时，会选择 preferred 副本作为新 leader 的一种方案。这也是控制器的职责范围。 集群成员管理：控制器能够监控新 broker 的增加，broker 的主动关闭与被动宕机，进而做其他工作。这里也是利用前面所说的 Zookeeper 的 ZNode 模型和 Watcher 机制，控制器会监听 Zookeeper 中 /brokers/ids 下临时节点的变化。 数据服务：控制器上保存了最全的集群元数据信息，其他所有 broker 会定期接收控制器发来的元数据更新请求，从而更新其内存中的缓存数据。 从上面内容我们大概知道，控制器可以说是 Kafka 的心脏，管理和协调着整个 Kafka 集群，因此控制器自身的性能和稳定性就变得至关重要。 社区在这方面做了大量工作，特别是在 0.11 版本中对控制器进行了重构，其中最大的改进把控制器内部多线程的设计改成了单线程加事件队列的方案，消除了多线程的资源消耗和线程安全问题，另外一个改进是把之前同步操作 Zookeeper 改为了异步操作，消除了 Zookeeper 端的性能瓶颈，大大提升了控制器的稳定性。 5. Kafka 消费端 Rebalance 机制 前面介绍消费者术语时，提到了消费组的概念，一个 topic 可以让若干个消费者进行消费，若干个消费者组成一个 Consumer Group 即消费组 ，一条消息只能被消费组中的一个消费者进行消费。我们用下图表示Kafka的消费模型。 5.1 Rebalance 概念 就 Kafka 消费端而言，有一个难以避免的问题就是消费者的重平衡即 Rebalance。Rebalance 是让一个消费组的所有消费者就如何消费订阅 topic 的所有分区达成共识的过程，在 Rebalance 过程中，所有 Consumer 实例都会停止消费，等待 Rebalance 的完成。因为要停止消费等待重平衡完成，因此 Rebalance 会严重影响消费端的 TPS，是应当尽量避免的。 5.2 Rebalance 发生条件 关于何时会发生 Rebalance，总结起来有三种情况： 消费组的消费者成员数量发生变化 消费主题的数量发生变化 消费主题的分区数量发生变化 其中后两种情况一般是计划内的，比如为了提高消息吞吐量增加 topic 分区数，这些情况一般是不可避免的，后面我们会重点讨论如何避免因为组内消费者成员数发生变化导致的 Rebalance。 5.3 Kafka 协调器 在介绍如何避免 Rebalance 问题之前，先来认识下 Kafka 的协调器 Coordinator，和之前 Kafka 控制器类似，Coordinator 也是 Kafka 的核心组件。 主要有两类 Kafka 协调器： 组协调器（Group Coordinator） 消费者协调器（Consumer Coordinator） Kafka 为了更好的实现消费组成员管理、位移管理，以及 Rebalance 等，broker 服务端引入了组协调器（Group Coordinator），消费端引入了消费者协调器（Consumer Coordinator）。每个 broker 启动的时候，都会创建一个 GroupCoordinator 实例，负责消费组注册、消费者成员记录、offset 等元数据操作，这里也可以看出每个 broker 都有自己的 Coordinator 组件。另外，每个 Consumer 实例化时，同时会创建一个 ConsumerCoordinator 实例，负责消费组下各个消费者和服务端组协调器之前的通信。可以用下图表示协调器原理： 客户端的消费者协调器 Consumer Coordinator 和服务端的组协调器 Group Coordinator 会通过心跳不断保持通信。 5.4 如何避免消费组 Rebalance 接下来我们讨论下如何避免组内消费者成员发生变化导致的 Rebalance。组内成员发生变化无非就两种情况，一种是有新的消费者加入，通常是我们为了提高消费速度增加了消费者数量，比如增加了消费线程或者多部署了一份消费程序，这种情况可以认为是正常的；另一种是有消费者退出，这种情况多是和我们消费端代码有关，是我们要重点避免的。 正常情况下，每个消费者都会定期向组协调器 Group Coordinator 发送心跳，表明自己还在存活，如果消费者不能及时的发送心跳，组协调器会认为该消费者已经“死”了，就会导致消费者离组引发 Rebalance 问题。这里涉及两个消费端参数：session.timeout.ms 和 heartbeat.interval.ms，含义分别是组协调器认为消费组存活的期限，和消费者发送心跳的时间间隔，其中 heartbeat.interval.ms 默认值是3s，session.timeout.ms 在 0.10.1 版本之前默认 30s，之后默认 10s。另外，0.10.1 版本还有两个值得注意的地方： 从该版本开始，Kafka 维护了单独的心跳线程，之前版本中 Kafka 是使用业务主线程发送的心跳。 增加了一个重要的参数 max.poll.interval.ms，表示 Consumer 两次调用 poll 方法拉取数据的最大时间间隔，默认值 5min，对于那些忙于业务逻辑处理导致超过 max.poll.interval.ms 时间的消费者将会离开消费组，此时将发生一次 Rebalance。 此外，如果 Consumer 端频繁 FullGC 也可能会导致消费端长时间停顿，从而引发 Rebalance。因此，我们总结如何避免消费组 Rebalance 问题，主要从以下几方面入手： 合理配置 session.timeout.ms 和 heartbeat.interval.ms，建议 0.10.1 之前适当调大 session 超时时间尽量规避 Rebalance。 根据实际业务调整 max.poll.interval.ms，通常建议调大避免 Rebalance，但注意 0.10.1 版本之前没有该参数。 监控消费端的 GC 情况，避免由于频繁 FullGC 导致线程长时间停顿引发 Rebalance。 合理调整以上参数，可以减少生产环境中 Rebalance 发生的几率，提升 Consumer 端的 TPS 和稳定性。 6.总结 本文总结了 Kafka 体系架构、Kafka 消息发送机制、副本机制，Kafka 控制器、消费端 Rebalance 机制等各方面核心原理，通过本文的介绍，相信你已经对 Kafka 的内核知识有了一定的掌握，更多的 Kafka 原理实践后面有时间再介绍。

燃财经（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如果只是为了春运和几个大的节假日去加技术和硬件，实际上也是不可行的。 说到底，铁路总运力是一定的，春运这个非常态的需求是极其巨大的，抢票软件并不能增加供给，也不会提高整体买到票的概率，抢票难的根本原因是供求关系不平衡。 加入阿里云钉钉群享福利：每周技术直播，定期群内有奖活动、大咖问答 阿里云开发者社区

HTTPS基本原理 一、http为什么不安全。 http协议没有任何的加密以及身份验证的机制，非常容易遭遇窃听、劫持、篡改，因此会造成个人隐私泄露，恶意的流量劫持等严重的安全问题。 国外很多网站都支持了全站https，国内方面目前百度已经在年初完成了搜索的全站https，其他大型的网站也在跟进中，百度最先完成全站https的最大原因就是百度作为国内最大的流量入口，劫持也必然是首当其冲的，造成的有形的和无形的损失也就越大。关于流量劫持问题，我在另一篇文章中也有提到，基本上是互联网企业的共同难题，https也是目前公认的比较好的解决方法。但是https也会带来很多性能以及访问速度上的牺牲，很多互联网公司在做大的时候都会遇到这个问题：https成本高，速度又慢，规模小的时候在涉及到登录和交易用上就够了，做大以后遇到信息泄露和劫持，想整体换，代价又很高。 2、https如何保证安全 要解决上面的问题，就要引入加密以及身份验证的机制。 这时我们引入了非对称加密的概念，我们知道非对称加密如果是公钥加密的数据私钥才能解密，所以我只要把公钥发给你，你就可以用这个公钥来加密未来我们进行数据交换的秘钥，发给我时，即使中间的人截取了信息，也无法解密，因为私钥在我这里，只有我才能解密，我拿到你的信息后用私钥解密后拿到加密数据用的对称秘钥，通过这个对称密钥来进行后续的数据加密。除此之外，非对称加密可以很好的管理秘钥，保证每次数据加密的对称密钥都是不相同的。 但是这样似乎还不够，如果中间人在收到我的给你公钥后并没有发给你，而是自己伪造了一个公钥发给你，这是你把对称密钥用这个公钥加密发回经过中间人，他可以用私钥解密并拿到对称密钥，此时他在把此对称密钥用我的公钥加密发回给我，这样中间人就拿到了对称密钥，可以解密传输的数据了。为了解决此问题，我们引入了数字证书的概念。我首先生成公私钥，将公钥提供给相关机构（CA），CA将公钥放入数字证书并将数字证书颁布给我，此时我就不是简单的把公钥给你，而是给你一个数字证书，数字证书中加入了一些数字签名的机制，保证了数字证书一定是我给你的。 所以综合以上三点： 非对称加密算法（公钥和私钥）交换秘钥 + 数字证书验证身份（验证公钥是否是伪造的） + 利用秘钥对称加密算法加密数据 = 安全 3、https协议简介 为什么是协议简介呢。因为https涉及的东西实在太多了，尤其是一些加密算法，非常的复杂，对于这些算法面的东西就不去深入研究了，这部分仅仅是梳理一下一些关于https最基本的原理，为后面分解https的连接建立以及https优化等内容打下理论基础。 3.1 对称加密算法 对称加密是指加密和解密使用相同密钥的加密算法。它要求发送方和接收方在安全通信之前，商定一个密钥。对称算法的安全性依赖于密钥，泄漏密钥就意味着任何人都可以对他们发送或接收的消息解密，所以密钥的保密性对通信至关重要。 对称加密又分为两种模式：流加密和分组加密。 流加密是将消息作为位流对待，并且使用数学函数分别作用在每一个位上，使用流加密时，每加密一次，相同的明文位会转换成不同的密文位。流加密使用了密钥流生成器，它生成的位流与明文位进行异或，从而生成密文。现在常用的就是RC4，不过RC4已经不再安全，微软也建议网络尽量不要使用RC4流加密。 分组加密是将消息划分为若干位分组，这些分组随后会通过数学函数进行处理，每次一个分组。假设需要加密发生给对端的消息，并且使用的是64位的分组密码，此时如果消息长度为640位，就会被划分成10个64位的分组，每个分组都用一系列数学公式公式进行处理，最后得到10个加密文本分组。然后，将这条密文消息发送给对端。对端必须拥有相同的分组密码，以相反的顺序对10个密文分组使用前面的算法解密，最终得到明文的消息。比较常用的分组加密算法有DES、3DES、AES。其中DES是比较老的加密算法，现在已经被证明不安全。而3DES是一个过渡的加密算法，相当于在DES基础上进行三重运算来提高安全性，但其本质上还是和DES算法一致。而AES是DES算法的替代算法，是现在最安全的对称加密算法之一。分组加密算法除了算法本身外还存在很多种不同的运算方式，比如ECB、CBC、CFB、OFB、CTR等，这些不同的模式可能只针对特定功能的环境中有效，所以要了解各种不同的模式以及每种模式的用途。这个部分后面的文章中会详细讲。 对称加密算法的优、缺点： 优点：算法公开、计算量小、加密速度快、加密效率高。 缺点：（1）交易双方都使用同样钥匙，安全性得不到保证； （2）每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量呈几何级数增长，密钥管理成为用户的负担。 （3）能提供机密性，但是不能提供验证和不可否认性。 3.2 非对称加密算法 在非对称密钥交换算法出现以前，对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题，使得对称密钥的生成和使用更加安全。 密钥交换算法本身非常复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等操作。 常见的密钥交换算法有RSA，ECDHE，DH，DHE等算法。涉及到比较复杂的数学问题，下面就简单介绍下最经典的RSA算法。RSA：算法实现简单，诞生于1977年，历史悠久，经过了长时间的破解测试，安全性高。缺点就是需要比较大的素数也就是质数（目前常用的是2048位）来保证安全强度，很消耗CPU运算资源。RSA是目前唯一一个既能用于密钥交换又能用于证书签名的算法。我觉得RSA可以算是最经典的非对称加密算法了，虽然算法本身都是数学的东西，但是作为最经典的算法，我自己也花了点时间对算法进行了研究，后面会详细介绍。 非对称加密相比对称加密更加安全，但也存在两个明显缺点： 1，CPU计算资源消耗非常大。一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。 2，非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。 所以公钥加密（极端消耗CPU资源）目前只能用来作密钥交换或者内容签名，不适合用来做应用层传输内容的加解密。 3.3 身份认证 https协议中身份认证的部分是由数字证书来完成的，证书由公钥、证书主体、数字签名等内容组成，在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证（验证查看这张证书是否是伪造的。也就是公钥是否是伪造的），并获取用于秘钥交换的非对称密钥（获取公钥）。 数字证书有两个作用： 1，身份授权。确保浏览器访问的网站是经过CA验证的可信任的网站。 2，分发公钥。每个数字证书都包含了注册者生成的公钥（验证确保是合法的，非伪造的公钥）。在SSL握手时会通过certificate消息传输给客户端。 申请一个受信任的数字证书通常有如下流程： 1，终端实体（可以是一个终端硬件或者网站）生成公私钥和证书请求。 2，RA（证书注册及审核机构）检查实体的合法性。如果个人或者小网站，这一步不是必须的。 3，CA（证书签发机构）签发证书，发送给申请者。 4，证书更新到repository（负责数字证书及CRL内容存储和分发），终端后续从repository更新证书，查询证书状态等。 数字证书验证： 申请者拿到CA的证书并部署在网站服务器端，那浏览器发起握手接收到证书后，如何确认这个证书就是CA签发的呢。怎样避免第三方伪造这个证书。答案就是数字签名（digital signature）。数字签名是证书的防伪标签，目前使用最广泛的SHA-RSA（SHA用于哈希算法，RSA用于非对称加密算法）数字签名的制作和验证过程如下： 1，数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用CA自己的私钥对消息摘要进行加密。 2，数字签名的校验。使用CA的公钥解密签名，然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。 需要注意的是： 1）数字签名签发和校验使用的密钥对是CA自己的公私密钥，跟证书申请者提交的公钥没有关系。 2）数字签名的签发过程跟公钥加密的过程刚好相反，即是用私钥加密，公钥解密。 3）现在大的CA都会有证书链，证书链的好处一是安全，保持根CA的私钥离线使用。第二个好处是方便部署和撤销，即如果证书出现问题，只需要撤销相应级别的证书，根证书依然安全。 4）根CA证书都是自签名，即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。 5）怎样获取根CA和多级CA的密钥对。它们是否可信。当然可信，因为这些厂商跟浏览器和操作系统都有合作，它们的公钥都默认装到了浏览器或者操作系统环境里。 3.4 数据完整性验证 数据传输过程中的完整性使用MAC算法来保证。为了避免网络中传输的数据被非法篡改，SSL利用基于MD5或SHA的MAC算法来保证消息的完整性。 MAC算法是在密钥参与下的数据摘要算法，能将密钥和任意长度的数据转换为固定长度的数据。发送者在密钥的参与下，利用MAC算法计算出消息的MAC值，并将其加在消息之后发送给接收者。接收者利用同样的密钥和MAC算法计算出消息的MAC值，并与接收到的MAC值比较。如果二者相同，则报文没有改变；否则，报文在传输过程中被修改，接收者将丢弃该报文。 由于MD5在实际应用中存在冲突的可能性比较大，所以尽量别采用MD5来验证内容一致性。SHA也不能使用SHA0和SHA1，中国山东大学的王小云教授在2005年就宣布破解了 SHA-1完整版算法。微软和google都已经宣布16年及17年之后不再支持sha1签名证书。MAC算法涉及到很多复杂的数学问题，这里就不多讲细节了。 专题二--【实际抓包分析】 抓包结果： fiddler： wireshark: 可以看到，百度和我们公司一样，也采用以下策略： （1）对于高版本浏览器，如果支持 https，且加解密算法在TLS1.0 以上的，都将所有 http请求重定向到 https请求 （2）对于https请求，则不变。 【以下只解读https请求】 1、TCP三次握手 可以看到，我们访问的是 http://www.baidu.com/ ， 在初次建立 三次握手的时候， 用户是去 连接 8080端口的（因为公司办公网做了代理，因此，我们实际和代理机做的三次握手，公司代理机再帮我们去连接百度服务器的80端口） 2、CONNECT 建立 由于公司办公网访问非腾讯域名，会做代理，因此，在进行https访问的时候，我们的电脑需要和公司代理机做 " CONNECT " 连接（关于 " CONNECT " 连接， 可以理解为虽然后续的https请求都是公司代理机和百度服务器进行公私钥连接和对称秘钥通信，但是，有了 " CONNECT " 连接之后，可以认为我们也在直接和百度服务器进行公私钥连接和对称秘钥通信。 ） fiddler抓包结果： CONNECT之后， 后面所有的通信过程，可以看做是我们的机器和百度服务器在直接通信 3、 client hello 整个 Secure Socket Layer只包含了： TLS1.2 Record Layer内容 （1）随机数 在客户端问候中，有四个字节以Unix时间格式记录了客户端的协调世界时间（UTC）。协调世界时间是从1970年1月1日开始到当前时刻所经历的秒数。在这个例子中，0x2516b84b就是协调世界时间。在他后面有28字节的随机数（ random_C ），在后面的过程中我们会用到这个随机数。 （2）SID（Session ID） 如果出于某种原因，对话中断，就需要重新握手。为了避免重新握手而造成的访问效率低下，这时候引入了session ID的概念， session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。 因为我们抓包的时候，是几个小时内第一次访问 https://www.baodu.com 首页，因此，这里并没有 Session ID. （稍会儿我们会看到隔了半分钟，第二次抓包就有这个Session ID） session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。 （3） 密文族（Cipher Suites）： RFC2246中建议了很多中组合，一般写法是"密钥交换算法-对称加密算法-哈希算法，以“TLS_RSA_WITH_AES_256_CBC_SHA”为例： （a） TLS为协议，RSA为密钥交换的算法； （b） AES_256_CBC是对称加密算法（其中256是密钥长度，CBC是分组方式）； （c） SHA是哈希的算法。 浏览器支持的加密算法一般会比较多，而服务端会根据自身的业务情况选择比较适合的加密组合发给客户端。（比如综合安全性以及速度、性能等因素） （4） Server_name扩展：（ 一般浏览器也支持 SNI（Server Name Indication）） 当我们去访问一个站点时，一定是先通过DNS解析出站点对应的ip地址，通过ip地址来访问站点，由于很多时候一个ip地址是给很多的站点公用，因此如果没有server_name这个字段，server是无法给与客户端相应的数字证书的，Server_name扩展则允许服务器对浏览器的请求授予相对应的证书。 还有一个很好的功能： SNI（Server Name Indication）。这个的功能比较好，为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。一句话简述它的工作原理就是，在连接到服务器建立SSL连接之前先发送要访问站点的域名（Hostname），这样服务器根据这个域名返回一个合适的CA证书。目前，大多数操作系统和浏览器都已经很好地支持SNI扩展，OpenSSL 0.9.8已经内置这一功能，据说新版的nginx也支持SNI。） 4、 服务器回复（包括 Server Hello， Certificate， Certificate Status） 服务器在收到client hello后，会回复三个数据包,下面分别看一下： 1）Server Hello 1、我们得到了服务器的以Unix时间格式记录的UTC和28字节的随机数 （random_S）。 2、Seesion ID，服务端对于session ID一般会有三种选择 （稍会儿我们会看到隔了半分钟，第二次抓包就有这个Session ID） ： 1）恢复的session ID：我们之前在client hello里面已经提到，如果client hello里面的session ID在服务端有缓存，服务端会尝试恢复这个session； 2）新的session ID：这里又分两种情况，第一种是client hello里面的session ID是空值，此时服务端会给客户端一个新的session ID，第二种是client hello里面的session ID此服务器并没有找到对应的缓存，此时也会回一个新的session ID给客户端； 3）NULL：服务端不希望此session被恢复，因此session ID为空。 3、我们记得在client hello里面，客户端给出了21种加密族，而在我们所提供的21个加密族中，服务端挑选了“TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256”。 （a） TLS为协议，RSA为密钥交换的算法； （b） AES_256_CBC是对称加密算法（其中256是密钥长度，CBC是分组方式）； （c） SHA是哈希的算法。 这就意味着服务端会使用ECDHE-RSA算法进行密钥交换，通过AES_128_GCM对称加密算法来加密数据，利用SHA256哈希算法来确保数据完整性。这是百度综合了安全、性能、访问速度等多方面后选取的加密组合。 2）Certificate 在前面的https原理研究中，我们知道为了安全的将公钥发给客户端，服务端会把公钥放入数字证书中并发给客户端（数字证书可以自签发，但是一般为了保证安全会有一个专门的CA机构签发），所以这个报文就是数字证书，4097 bytes就是证书的长度。 我们打开这个证书，可以看到证书的具体信息，这个具体信息通过抓包报文的方式不是太直观，可以在浏览器上直接看。 （点击 chrome 浏览器 左上方的 绿色 锁型按钮） 3）Server Hello Done 我们抓的包是将 Server Hello Done 和 server key exchage 合并的包： 4）客户端验证证书真伪性 客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下： 证书链的可信性trusted certificate path，方法如前文所述； 证书是否吊销revocation，有两类方式离线CRL与在线OCSP，不同的客户端行为会不同； 有效期expiry date，证书是否在有效时间范围； 域名domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析； 5）秘钥交换 这个过程非常复杂，大概总结一下： （1）首先，其利用非对称加密实现身份认证和密钥协商，利用非对称加密，协商好加解密数据的 对称秘钥（外加CA认证，防止中间人窃取 对称秘钥） （2）然后，对称加密算法采用协商的密钥对数据加密，客户端和服务器利用 对称秘钥 进行通信； （3）最后，基于散列函数验证信息的完整性，确保通信数据不会被中间人恶意篡改。 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数random_C和random_S与自己计算产生的Pre-master（由客户端和服务器的 pubkey生成的一串随机数），计算得到协商对称密钥; enc_key=Fuc(random_C, random_S, Pre-Master) 6）生成 session ticket 如果出于某种原因，对话中断，就需要重新握手。为了避免重新握手而造成的访问效率低下，这时候引入了session ID的概念， session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的"对话密钥"，而不必重新生成一把。 因为我们抓包的时候，是几个小时内第一次访问 https://www.baodu.com 首页，因此，这里并没有 Session ID. （稍会儿我们会看到隔了半分钟，第二次抓包就有这个Session ID） session ID是目前所有浏览器都支持的方法，但是它的缺点在于session ID往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。 后续建立新的https会话，就可以利用 session ID 或者 session Tickets ， 对称秘钥可以再次使用，从而免去了 https 公私钥交换、CA认证等等过程，极大地缩短 https 会话连接时间。 7） 利用对称秘钥传输数据 【半分钟后，再次访问百度】： 有这些大的不同： 由于服务器和浏览器缓存了 Session ID 和 Session Tickets，不需要再进行 公钥证书传递，CA认证，生成 对称秘钥等过程，直接利用半分钟前的 对称秘钥 加解密数据进行会话。 1）Client Hello 2）Server Hello