对象接口定义语言问题怎么解决

Kotlin的简介 Kotlin是由JetBrains公司（IDEA开发者）所开发的编程语言，其名称来自于开发团队附近的科特林岛。 多平台开发 JVM ：Android; Server-Side Javascript:前端 Native(beta) :开发原生应用 windows、macos、linux Swift与Kotlin非常像 http://nilhcem.com/swift-is-like-kotlin/ kotlin发展历程 image.png java发展历程 image.png JVM语言的原理 image.png JVM规范与java规范是相互独立的 只要生成的编译文件匹配JVM字节码规范，任何语言都可以由JVM编译运行. Kotlin也是一种JVM语言，完全兼容java，可以与java相互调用；Kotlin语言的设计受到Java、C#、JavaScript、Scala、Groovy等语言的启发 kotlin的特性 下面不会罗列kotlin中具体的语法，会介绍我认为比较重要的特性，以及特性背后的东西。 类型推断 空类型设计 函数式编程 类型推断 image.png 类型推断是指编程语言中在编译期自动推导出值的数据类型。推断类型的能力让很多编程任务变得容易，让程序员可以忽略类型标注的同时仍然允许类型检查。 在开发环境中，我们往往写出表达式，然后可以用快捷键来生成变量声明，往往都是很准的，这说明了编译器其实是可以很准确的推断出来类型的。编程语言所具备的类型推断能力可以把类型声明的任务由开发者转到了编译器. java中声明变量的方式是类型写在最前面，后面跟着变量名，这就迫使开发者在声明变量时就要先思考变量的类型要定义成什么，而在一些情况下比如使用集合、泛型类型的变量，定义类型就会变得比较繁琐。 Kotlin中声明变量，类型可以省略，或者放到变量名后面，这可以降低类型的权重，从必选变为可选，降低开发者思维负担。java10中也引入了类型推断。 Javascript中声明变量也是用关键字var,但是还是有本质区别的，Kotlin中的类型推断并不是变成动态类型、弱类型，类型仍然是在编译期就已经决定了的，Kotlin仍然是静态类型、强类型的编程语言。javascript由于是弱类型语言，同一个变量可以不经过强制类型转换就被赋不同数据类型的值， 编程语言的一个趋势就是抽象程度越来越高，编译器做更多的事情。 空类型设计 空类型的由来 image.png 托尼·霍尔（Tony Hoare），图灵奖得主 托尼·霍尔是ALGOL语言的设计者，该语言在编程语言发展历史上非常重要,对其他编程语言产生重大影响，大多数近代编程语言(包括C语言)皆使用类似ALGOL的语法。他在一次大会上讨论了null应用的设计： “我把 null 引用称为自己的十亿美元错误。它的发明是在1965 年，那时我用一个面向对象语言( ALGOL W )设计了第一个全面的引用类型系统。我加入了null引用设计，仅仅是因为实现起来非常容易。它导致了数不清的错误、漏洞和系统崩溃，可能在之后 40 年中造成了十亿美元的损失。” null引用存在的问题 以java为例，看null引用的设计到底存在哪些问题 空指针问题NPE 编译时不能对空指针做出检查，运行时访问null对象就会出现错误，这个就是工程中常见的空指针异常。 null本身没有语义，会存在歧义 值未被初始化 值不存在 也许表示一种状态 逻辑上有漏洞 Java中，null可以赋值给任何引用，比如赋值给String类型变量，String a = null，但是null并不是String类型： a instanceof String 返回的是false，这个其实是有些矛盾的。所以当持有一个String类型的变量，就存在两种情况，null或者真正的String. 解决NPE的方式 防御式代码 在访问对象前判空，但会有冗余代码；会规避问题，而隐藏真正的问题 抛出异常给调用方处理 方法中传参传入的空值、无效值，抛出受检查异常给上层调用方 增加注解 Android中可以增加@NonNull注解，编译时做额外检查 空状态对象设计模式 空状态对象是一个实现接口但是不做任何业务逻辑的对象，可以取代判空检查；这样的空状态对象也可以在数据不可用的时候提供默认的行为 java8 Optional类 java8中引入了Optional类，来解决广泛存在的null引用问题.官方javadoc文档介绍 A container object which may or may not contain a non-null value. If a value is present, isPresent() will return true and get() will return the value. Additional methods that depend on the presence or absence of a contained value are provided, such as orElse() (return a default value if value not present) and ifPresent() (execute a block of code if the value is present). 来看一下是如何实现的。 举一个访问对象读取熟悉的例子 java 8 之前 : image.png java 8: image.png 总结： 1.用Optional还是会比较繁琐，这个也说明了设计一个替代null的方案还是比较难的。 optional的耗时大约是普通判空的数十倍，主要是涉及泛型、使用时多创键了一个对象的创建；数据比较大时，会造成性能损失。 java8 引入Optional的意义在于提示调用者，用特殊类型包装的变量可能为空，在使用取出时需要判断 Kotlin的空类型设计 Kotlin中引入了可空类型和不可空类型的区分，可以区分一个引用可以容纳null,还是不能容纳null。 String vs String? String 类型表示变量不能为空，String?则表示变量可以为空 String?含义是String or null.这两种是不同的类型. 比如： var a:String = “abc” //ok var a:String = null //不允许 var b :String? = null //ok a=b // 不允许 String?类型的值不能给String类型的值赋值 这样就将类型分成了可空类型和不可能类型,每一个类型都有这样的处理;Kotlin中访问非空类型变量永远不会出现空指针异常。 同样上面的例子，采用Kotlin去写，就会简洁很多 image.png 编程范式-函数式编程 编程范式是什么？ 编程范式是程序员看待程序和写程序的观点 主要的类型 非结构化编程 结构化编程 面向对象编程 命令式编程 函数式编程 这些类型并不是彼此互斥的，而是按照不同的维度做的划分，一种编程语言可能都支持多个编程范式 非结构化编程 第一代的高级语言往往是非结构化编程 比如 BASIC语言 每一行的代码前面都有一个数字作为行号,通常使用GOTO的跳跃指令来实现判断和循环. 看一下下面这段代码是做什么的： image.png 实际上做的是：程序在屏幕上显示数字 1 到 10 及其对应的平方 采用这种方式写程序，大量的使用goto实现逻辑的跳转，代码一长，可读性和维护性就比较差了，形成“面条式代码” 结构化编程 采用顺序、分支、循环结构来表达，禁用或者少用GOTO; 并用子程序来组织代码，采用自顶向下的方式来写程序 代表语言是C语言 实现同样的逻辑： image.png 可见采用结构化编程，代码的逻辑会更清晰。 面向对象编程 思想： 将计算机程序视为一组对象的集合，而每个对象都可以接收其他对象发过来的消息，并处理这些消息，计算机程序的执行就是一系列消息在各个对象之间传递。 特性： 封装性、继承性、多态性。 命令式编程 把计算机程序视为一系列的命令集合 主要思想是关注计算机执行的步骤，即一步一步告诉计算机先做什么再做什么。 “先做这，再做那”，强调“怎么做” 实现： 用变量来储存数据，用语句来执行指令，改变变量状态。 基本所有的常见的编程语言都具有此范式 函数式编程 声明式语法，描述要什么，而不是怎么做 类似于SQL语句 语言： kotlin swift python javascript scala 函数是第一等公民 可以赋值给变量，可作为参数传入另一个函数，也可作为函数的返回值 纯函数 y=f(x) 只要输入相同，返回值不变 没有副作用：不修改函数的外部状态 举个栗子 公司部门要进行outing，去哪里是个问题，要考虑多个因素，比如花费、距离、天数等等，有多个备选地点进行选择。 定义一个数据类： image.png 要进行筛选了，分别用sql,kotlin,java来实现 找出花费低于2000元的outing地点信息 SQL image.png Kotlin image.png java 7 image.png 可见kotin的写法还是比较接近于sql的思想的，声明式的写法，而不管具体如何实现；其中的：place->place.money<2000 就是函数，可以作为参数传递给fliter这个高阶函数；而且这个函数没有副作用，不改变外部状态。 再来一个复杂一点的： 找出花费低于5000元，时间不多于4天，按照距离排序的outing地点名称 SQL image.png Kotlin: image.png java 7 image.png 由此可见用kotlin的函数式写法，会更简洁，逻辑也更清晰，这段代码的目标一目了然，这种清晰在于实现了业务逻辑与控制逻辑的分离，业务逻辑就是由函数实现的，比如place->place.money<500,而控制逻辑是由filter,sorterBy等高阶函数实现的。 而java的传统写法是基于对数据的操作，避免不了遍历的操作，业务逻辑与控制逻辑交织在了一起，这段代码的目的就不是那么容易清晰看到的了。 总结 kotlin是实用的现代编程语言，吸收了众多编程语言的优点，支持类型推断、空类型安全、函数式编程、DSL等特性，非常值得学习和使用。

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

遍历一个 List 有哪些不同的方式？每种方法的实现原理是什么？Java 中 List 遍历的最佳实践是什么？ 遍历方式有以下几种： for 循环遍历，基于计数器。在集合外部维护一个计数器，然后依次读取每一个位置的元素，当读取到最后一个元素后停止。 迭代器遍历，Iterator。Iterator 是面向对象的一个设计模式，目的是屏蔽不同数据集合的特点，统一遍历集合的接口。Java 在 Collections 中支持了 Iterator 模式。 foreach 循环遍历。foreach 内部也是采用了 Iterator 的方式实现，使用时不需要显式声明 Iterator 或计数器。优点是代码简洁，不易出错；缺点是只能做简单的遍历，不能在遍历过程中操作数据集合，例如删除、替换。 最佳实践：Java Collections 框架中提供了一个 RandomAccess 接口，用来标记 List 实现是否支持 Random Access。 如果一个数据集合实现了该接口，就意味着它支持 Random Access，按位置读取元素的平均时间复杂度为 O(1)，如ArrayList。如果没有实现该接口，表示不支持 Random Access，如LinkedList。 推荐的做法就是，支持 Random Access 的列表可用 for 循环遍历，否则建议用 Iterator 或 foreach 遍历。 说一下 ArrayList 的优缺点 ArrayList的优点如下： ArrayList 底层以数组实现，是一种随机访问模式。ArrayList 实现了 RandomAccess 接口，因此查找的时候非常快。ArrayList 在顺序添加一个元素的时候非常方便。 ArrayList 的缺点如下： 删除元素的时候，需要做一次元素复制操作。如果要复制的元素很多，那么就会比较耗费性能。插入元素的时候，也需要做一次元素复制操作，缺点同上。 ArrayList 比较适合顺序添加、随机访问的场景。 如何实现数组和 List 之间的转换？ 数组转 List：使用 Arrays. asList(array) 进行转换。List 转数组：使用 List 自带的 toArray() 方法。 代码示例： ArrayList 和 LinkedList 的区别是什么？ 数据结构实现：ArrayList 是动态数组的数据结构实现，而 LinkedList 是双向链表的数据结构实现。随机访问效率：ArrayList 比 LinkedList 在随机访问的时候效率要高，因为 LinkedList 是线性的数据存储方式，所以需要移动指针从前往后依次查找。增加和删除效率：在非首尾的增加和删除操作，LinkedList 要比 ArrayList 效率要高，因为 ArrayList 增删操作要影响数组内的其他数据的下标。内存空间占用：LinkedList 比 ArrayList 更占内存，因为 LinkedList 的节点除了存储数据，还存储了两个引用，一个指向前一个元素，一个指向后一个元素。线程安全：ArrayList 和 LinkedList 都是不同步的，也就是不保证线程安全； 综合来说，在需要频繁读取集合中的元素时，更推荐使用 ArrayList，而在插入和删除操作较多时，更推荐使用 LinkedList。 补充：数据结构基础之双向链表 双向链表也叫双链表，是链表的一种，它的每个数据结点中都有两个指针，分别指向直接后继和直接前驱。所以，从双向链表中的任意一个结点开始，都可以很方便地访问它的前驱结点和后继结点。 ArrayList 和 Vector 的区别是什么？ 这两个类都实现了 List 接口（List 接口继承了 Collection 接口），他们都是有序集合 线程安全：Vector 使用了 Synchronized 来实现线程同步，是线程安全的，而 ArrayList 是非线程安全的。性能：ArrayList 在性能方面要优于 Vector。扩容：ArrayList 和 Vector 都会根据实际的需要动态的调整容量，只不过在 Vector 扩容每次会增加 1 倍，而 ArrayList 只会增加 50%。 Vector类的所有方法都是同步的。可以由两个线程安全地访问一个Vector对象、但是一个线程访问Vector的话代码要在同步操作上耗费大量的时间。 Arraylist不是同步的，所以在不需要保证线程安全时时建议使用Arraylist。 插入数据时，ArrayList、LinkedList、Vector谁速度较快？阐述 ArrayList、Vector、LinkedList 的存储性能和特性？ ArrayList、LinkedList、Vector 底层的实现都是使用数组方式存储数据。数组元素数大于实际存储的数据以便增加和插入元素，它们都允许直接按序号索引元素，但是插入元素要涉及数组元素移动等内存操作，所以索引数据快而插入数据慢。 Vector 中的方法由于加了 synchronized 修饰，因此 Vector 是线程安全容器，但性能上较ArrayList差。 LinkedList 使用双向链表实现存储，按序号索引数据需要进行前向或后向遍历，但插入数据时只需要记录当前项的前后项即可，所以 LinkedList 插入速度较快。 多线程场景下如何使用 ArrayList？ ArrayList 不是线程安全的，如果遇到多线程场景，可以通过 Collections 的 synchronizedList 方法将其转换成线程安全的容器后再使用。例如像下面这样： 为什么 ArrayList 的 elementData 加上 transient 修饰？ ArrayList 中的数组定义如下： private transient Object[] elementData; 再看一下 ArrayList 的定义： public class ArrayList extends AbstractList implements List<E>, RandomAccess, Cloneable, java.io.Serializable 可以看到 ArrayList 实现了 Serializable 接口，这意味着 ArrayList 支持序列化。transient 的作用是说不希望 elementData 数组被序列化，重写了 writeObject 实现： 每次序列化时，先调用 defaultWriteObject() 方法序列化 ArrayList 中的非 transient 元素，然后遍历 elementData，只序列化已存入的元素，这样既加快了序列化的速度，又减小了序列化之后的文件大小。 List 和 Set 的区别 List , Set 都是继承自Collection 接口 List 特点：一个有序（元素存入集合的顺序和取出的顺序一致）容器，元素可以重复，可以插入多个null元素，元素都有索引。常用的实现类有 ArrayList、LinkedList 和 Vector。 Set 特点：一个无序（存入和取出顺序有可能不一致）容器，不可以存储重复元素，只允许存入一个null元素，必须保证元素唯一性。Set 接口常用实现类是 HashSet、LinkedHashSet 以及 TreeSet。 另外 List 支持for循环，也就是通过下标来遍历，也可以用迭代器，但是set只能用迭代，因为他无序，无法用下标来取得想要的值。 Set和List对比 Set：检索元素效率低下，删除和插入效率高，插入和删除不会引起元素位置改变。 List：和数组类似，List可以动态增长，查找元素效率高，插入删除元素效率低，因为会引起其他元素位置改变 Set接口 说一下 HashSet 的实现原理？ HashSet 是基于 HashMap 实现的，HashSet的值存放于HashMap的key上，HashMap的value统一为PRESENT，因此 HashSet 的实现比较简单，相关 HashSet 的操作，基本上都是直接调用底层 HashMap 的相关方法来完成，HashSet 不允许重复的值。 HashSet如何检查重复？HashSet是如何保证数据不可重复的？ 向HashSet 中add ()元素时，判断元素是否存在的依据，不仅要比较hash值，同时还要结合equles 方法比较。 HashSet 中的add ()方法会使用HashMap 的put()方法。 HashMap 的 key 是唯一的，由源码可以看出 HashSet 添加进去的值就是作为HashMap 的key，并且在HashMap中如果K/V相同时，会用新的V覆盖掉旧的V，然后返回旧的V。所以不会重复（ HashMap 比较key是否相等是先比较hashcode 再比较equals ）。 以下是HashSet 部分源码： hashCode（）与equals（）的相关规定： 如果两个对象相等，则hashcode一定也是相同的 两个对象相等,对两个equals方法返回true 两个对象有相同的hashcode值，它们也不一定是相等的 综上，equals方法被覆盖过，则hashCode方法也必须被覆盖 hashCode()的默认行为是对堆上的对象产生独特值。如果没有重写hashCode()，则该class的两个对象无论如何都不会相等（即使这两个对象指向相同的数据）。 ** ==与equals的区别** ==是判断两个变量或实例是不是指向同一个内存空间 equals是判断两个变量或实例所指向的内存空间的值是不是相同 ==是指对内存地址进行比较 equals()是对字符串的内容进行比较3.==指引用是否相同 equals()指的是值是否相同 HashSet与HashMap的区别 Queue BlockingQueue是什么？ Java.util.concurrent.BlockingQueue是一个队列，在进行检索或移除一个元素的时候，它会等待队列变为非空；当在添加一个元素时，它会等待队列中的可用空间。BlockingQueue接口是Java集合框架的一部分，主要用于实现生产者-消费者模式。我们不需要担心等待生产者有可用的空间，或消费者有可用的对象，因为它都在BlockingQueue的实现类中被处理了。Java提供了集中BlockingQueue的实现，比如ArrayBlockingQueue、LinkedBlockingQueue、PriorityBlockingQueue,、SynchronousQueue等。 在 Queue 中 poll()和 remove()有什么区别？ 相同点：都是返回第一个元素，并在队列中删除返回的对象。 不同点：如果没有元素 poll()会返回 null，而 remove()会直接抛出 NoSuchElementException 异常。 代码示例： Queue queue = new LinkedList (); queue. offer("string"); // add System. out. println(queue. poll()); System. out. println(queue. remove()); System. out. println(queue. size()); Map接口 说一下 HashMap 的实现原理？ HashMap概述： HashMap是基于哈希表的Map接口的非同步实现。此实现提供所有可选的映射操作，并允许使用null值和null键。此类不保证映射的顺序，特别是它不保证该顺序恒久不变。 HashMap的数据结构： 在Java编程语言中，最基本的结构就是两种，一个是数组，另外一个是模拟指针（引用），所有的数据结构都可以用这两个基本结构来构造的，HashMap也不例外。HashMap实际上是一个“链表散列”的数据结构，即数组和链表的结合体。 HashMap 基于 Hash 算法实现的 当我们往Hashmap中put元素时，利用key的hashCode重新hash计算出当前对象的元素在数组中的下标存储时，如果出现hash值相同的key，此时有两种情况。(1)如果key相同，则覆盖原始值；(2)如果key不同（出现冲突），则将当前的key-value放入链表中获取时，直接找到hash值对应的下标，在进一步判断key是否相同，从而找到对应值。理解了以上过程就不难明白HashMap是如何解决hash冲突的问题，核心就是使用了数组的存储方式，然后将冲突的key的对象放入链表中，一旦发现冲突就在链表中做进一步的对比。 需要注意Jdk 1.8中对HashMap的实现做了优化，当链表中的节点数据超过八个之后，该链表会转为红黑树来提高查询效率，从原来的O(n)到O(logn) HashMap在JDK1.7和JDK1.8中有哪些不同？HashMap的底层实现 在Java中，保存数据有两种比较简单的数据结构：数组和链表。数组的特点是：寻址容易，插入和删除困难；链表的特点是：寻址困难，但插入和删除容易；所以我们将数组和链表结合在一起，发挥两者各自的优势，使用一种叫做拉链法的方式可以解决哈希冲突。 JDK1.8之前 JDK1.8之前采用的是拉链法。拉链法：将链表和数组相结合。也就是说创建一个链表数组，数组中每一格就是一个链表。若遇到哈希冲突，则将冲突的值加到链表中即可。 JDK1.8之后 相比于之前的版本，jdk1.8在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。 JDK1.7 VS JDK1.8 比较 JDK1.8主要解决或优化了一下问题： resize 扩容优化引入了红黑树，目的是避免单条链表过长而影响查询效率，红黑树算法请参考解决了多线程死循环问题，但仍是非线程安全的，多线程时可能会造成数据丢失问题。 HashMap的put方法的具体流程？ 当我们put的时候，首先计算 key的hash值，这里调用了 hash方法，hash方法实际是让key.hashCode()与key.hashCode()>>>16进行异或操作，高16bit补0，一个数和0异或不变，所以 hash 函数大概的作用就是：高16bit不变，低16bit和高16bit做了一个异或，目的是减少碰撞。按照函数注释，因为bucket数组大小是2的幂，计算下标index = (table.length - 1) & hash，如果不做 hash 处理，相当于散列生效的只有几个低 bit 位，为了减少散列的碰撞，设计者综合考虑了速度、作用、质量之后，使用高16bit和低16bit异或来简单处理减少碰撞，而且JDK8中用了复杂度 O（logn）的树结构来提升碰撞下的性能。 putVal方法执行流程图 ①.判断键值对数组table[i]是否为空或为null，否则执行resize()进行扩容； ②.根据键值key计算hash值得到插入的数组索引i，如果table[i]==null，直接新建节点添加，转向⑥，如果table[i]不为空，转向③； ③.判断table[i]的首个元素是否和key一样，如果相同直接覆盖value，否则转向④，这里的相同指的是hashCode以及equals； ④.判断table[i] 是否为treeNode，即table[i] 是否是红黑树，如果是红黑树，则直接在树中插入键值对，否则转向⑤； ⑤.遍历table[i]，判断链表长度是否大于8，大于8的话把链表转换为红黑树，在红黑树中执行插入操作，否则进行链表的插入操作；遍历过程中若发现key已经存在直接覆盖value即可； ⑥.插入成功后，判断实际存在的键值对数量size是否超多了最大容量threshold，如果超过，进行扩容。 HashMap的扩容操作是怎么实现的？ ①.在jdk1.8中，resize方法是在hashmap中的键值对大于阀值时或者初始化时，就调用resize方法进行扩容； ②.每次扩展的时候，都是扩展2倍； ③.扩展后Node对象的位置要么在原位置，要么移动到原偏移量两倍的位置。 在putVal()中，我们看到在这个函数里面使用到了2次resize()方法，resize()方法表示的在进行第一次初始化时会对其进行扩容，或者当该数组的实际大小大于其临界值值(第一次为12),这个时候在扩容的同时也会伴随的桶上面的元素进行重新分发，这也是JDK1.8版本的一个优化的地方，在1.7中，扩容之后需要重新去计算其Hash值，根据Hash值对其进行分发，但在1.8版本中，则是根据在同一个桶的位置中进行判断(e.hash & oldCap)是否为0，重新进行hash分配后，该元素的位置要么停留在原始位置，要么移动到原始位置+增加的数组大小这个位置上 HashMap是怎么解决哈希冲突的？ 答：在解决这个问题之前，我们首先需要知道什么是哈希冲突，而在了解哈希冲突之前我们还要知道什么是哈希才行； 什么是哈希？ Hash，一般翻译为“散列”，也有直接音译为“哈希”的，这就是把任意长度的输入通过散列算法，变换成固定长度的输出，该输出就是散列值（哈希值）；这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，所以不可能从散列值来唯一的确定输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。 所有散列函数都有如下一个基本特性**：根据同一散列函数计算出的散列值如果不同，那么输入值肯定也不同。但是，根据同一散列函数计算出的散列值如果相同，输入值不一定相同**。 什么是哈希冲突？ 当两个不同的输入值，根据同一散列函数计算出相同的散列值的现象，我们就把它叫做碰撞（哈希碰撞）。 HashMap的数据结构 在Java中，保存数据有两种比较简单的数据结构：数组和链表。数组的特点是：寻址容易，插入和删除困难；链表的特点是：寻址困难，但插入和删除容易；所以我们将数组和链表结合在一起，发挥两者各自的优势，使用一种叫做链地址法的方式可以解决哈希冲突： 这样我们就可以将拥有相同哈希值的对象组织成一个链表放在hash值所对应的bucket下，但相比于hashCode返回的int类型，我们HashMap初始的容量大小DEFAULT_INITIAL_CAPACITY = 1 << 4（即2的四次方16）要远小于int类型的范围，所以我们如果只是单纯的用hashCode取余来获取对应的bucket这将会大大增加哈希碰撞的概率，并且最坏情况下还会将HashMap变成一个单链表，所以我们还需要对hashCode作一定的优化 hash()函数 上面提到的问题，主要是因为如果使用hashCode取余，那么相当于参与运算的只有hashCode的低位，高位是没有起到任何作用的，所以我们的思路就是让hashCode取值出的高位也参与运算，进一步降低hash碰撞的概率，使得数据分布更平均，我们把这样的操作称为扰动，在JDK 1.8中的hash()函数如下： static final int hash(Object key) { int h; return (key == null) ? 0 : (h = key.hashCode()) ^ (h >>> 16);// 与自己右移16位进行异或运算（高低位异或） } 这比在JDK 1.7中，更为简洁，相比在1.7中的4次位运算，5次异或运算（9次扰动），在1.8中，只进行了1次位运算和1次异或运算（2次扰动）； JDK1.8新增红黑树 通过上面的链地址法（使用散列表）和扰动函数我们成功让我们的数据分布更平均，哈希碰撞减少，但是当我们的HashMap中存在大量数据时，加入我们某个bucket下对应的链表有n个元素，那么遍历时间复杂度就为O(n)，为了针对这个问题，JDK1.8在HashMap中新增了红黑树的数据结构，进一步使得遍历复杂度降低至O(logn)； 总结 简单总结一下HashMap是使用了哪些方法来有效解决哈希冲突的： 使用链地址法（使用散列表）来链接拥有相同hash值的数据；使用2次扰动函数（hash函数）来降低哈希冲突的概率，使得数据分布更平均；引入红黑树进一步降低遍历的时间复杂度，使得遍历更快； **能否使用任何类作为 Map 的 key？ **可以使用任何类作为 Map 的 key，然而在使用之前，需要考虑以下几点： 如果类重写了 equals() 方法，也应该重写 hashCode() 方法。 类的所有实例需要遵循与 equals() 和 hashCode() 相关的规则。 如果一个类没有使用 equals()，不应该在 hashCode() 中使用它。 用户自定义 Key 类最佳实践是使之为不可变的，这样 hashCode() 值可以被缓存起来，拥有更好的性能。不可变的类也可以确保 hashCode() 和 equals() 在未来不会改变，这样就会解决与可变相关的问题了。 为什么HashMap中String、Integer这样的包装类适合作为K？ 答：String、Integer等包装类的特性能够保证Hash值的不可更改性和计算准确性，能够有效的减少Hash碰撞的几率 都是final类型，即不可变性，保证key的不可更改性，不会存在获取hash值不同的情况 内部已重写了equals()、hashCode()等方法，遵守了HashMap内部的规范（不清楚可以去上面看看putValue的过程），不容易出现Hash值计算错误的情况； 如果使用Object作为HashMap的Key，应该怎么办呢？ 答：重写hashCode()和equals()方法 重写hashCode()是因为需要计算存储数据的存储位置，需要注意不要试图从散列码计算中排除掉一个对象的关键部分来提高性能，这样虽然能更快但可能会导致更多的Hash碰撞； 重写equals()方法，需要遵守自反性、对称性、传递性、一致性以及对于任何非null的引用值x，x.equals(null)必须返回false的这几个特性，目的是为了保证key在哈希表中的唯一性； HashMap为什么不直接使用hashCode()处理后的哈希值直接作为table的下标 答：hashCode()方法返回的是int整数类型，其范围为-(2 ^ 31)~(2 ^ 31 - 1)，约有40亿个映射空间，而HashMap的容量范围是在16（初始化默认值）~2 ^ 30，HashMap通常情况下是取不到最大值的，并且设备上也难以提供这么多的存储空间，从而导致通过hashCode()计算出的哈希值可能不在数组大小范围内，进而无法匹配存储位置； 那怎么解决呢？ HashMap自己实现了自己的hash()方法，通过两次扰动使得它自己的哈希值高低位自行进行异或运算，降低哈希碰撞概率也使得数据分布更平均； 在保证数组长度为2的幂次方的时候，使用hash()运算之后的值与运算（&）（数组长度 - 1）来获取数组下标的方式进行存储，这样一来是比取余操作更加有效率，二来也是因为只有当数组长度为2的幂次方时，h&(length-1)才等价于h%length，三来解决了“哈希值与数组大小范围不匹配”的问题； HashMap 的长度为什么是2的幂次方 为了能让 HashMap 存取高效，尽量较少碰撞，也就是要尽量把数据分配均匀，每个链表/红黑树长度大致相同。这个实现就是把数据存到哪个链表/红黑树中的算法。 这个算法应该如何设计呢？ 我们首先可能会想到采用%取余的操作来实现。但是，重点来了：“取余(%)操作中如果除数是2的幂次则等价于与其除数减一的与(&)操作（也就是说 hash%length==hash&(length-1)的前提是 length 是2的 n 次方；）。” 并且 采用二进制位操作 &，相对于%能够提高运算效率，这就解释了 HashMap 的长度为什么是2的幂次方。 那为什么是两次扰动呢？ 答：这样就是加大哈希值低位的随机性，使得分布更均匀，从而提高对应数组存储下标位置的随机性&均匀性，最终减少Hash冲突，两次就够了，已经达到了高位低位同时参与运算的目的； HashMap 与 HashTable 有什么区别？ 线程安全： HashMap 是非线程安全的，HashTable 是线程安全的；HashTable 内部的方法基本都经过 synchronized 修饰。（如果你要保证线程安全的话就使用 ConcurrentHashMap 吧！）； 效率： 因为线程安全的问题，HashMap 要比 HashTable 效率高一点。另外，HashTable 基本被淘汰，不要在代码中使用它； 对Null key 和Null value的支持： HashMap 中，null 可以作为键，这样的键只有一个，可以有一个或多个键所对应的值为 null。但是在 HashTable 中 put 进的键值只要有一个 null，直接抛NullPointerException。 **初始容量大小和每次扩充容量大小的不同 **： ①创建时如果不指定容量初始值，Hashtable 默认的初始大小为11，之后每次扩充，容量变为原来的2n+1。HashMap 默认的初始化大小为16。之后每次扩充，容量变为原来的2倍。②创建时如果给定了容量初始值，那么 Hashtable 会直接使用你给定的大小，而 HashMap 会将其扩充为2的幂次方大小。也就是说 HashMap 总是使用2的幂作为哈希表的大小，后面会介绍到为什么是2的幂次方。 底层数据结构： JDK1.8 以后的 HashMap 在解决哈希冲突时有了较大的变化，当链表长度大于阈值（默认为8）时，将链表转化为红黑树，以减少搜索时间。Hashtable 没有这样的机制。 推荐使用：在 Hashtable 的类注释可以看到，Hashtable 是保留类不建议使用，推荐在单线程环境下使用 HashMap 替代，如果需要多线程使用则用 ConcurrentHashMap 替代。 如何决定使用 HashMap 还是 TreeMap？ 对于在Map中插入、删除和定位元素这类操作，HashMap是最好的选择。然而，假如你需要对一个有序的key集合进行遍历，TreeMap是更好的选择。基于你的collection的大小，也许向HashMap中添加元素会更快，将map换为TreeMap进行有序key的遍历。 HashMap 和 ConcurrentHashMap 的区别 ConcurrentHashMap对整个桶数组进行了分割分段(Segment)，然后在每一个分段上都用lock锁进行保护，相对于HashTable的synchronized锁的粒度更精细了一些，并发性能更好，而HashMap没有锁机制，不是线程安全的。（JDK1.8之后ConcurrentHashMap启用了一种全新的方式实现,利用CAS算法。） HashMap的键值对允许有null，但是ConCurrentHashMap都不允许。 ConcurrentHashMap 和 Hashtable 的区别？ ConcurrentHashMap 和 Hashtable 的区别主要体现在实现线程安全的方式上不同。 底层数据结构： JDK1.7的 ConcurrentHashMap 底层采用 分段的数组+链表 实现，JDK1.8 采用的数据结构跟HashMap1.8的结构一样，数组+链表/红黑二叉树。Hashtable 和 JDK1.8 之前的 HashMap 的底层数据结构类似都是采用 数组+链表 的形式，数组是 HashMap 的主体，链表则是主要为了解决哈希冲突而存在的； 实现线程安全的方式（重要）： ① 在JDK1.7的时候，ConcurrentHashMap（分段锁） 对整个桶数组进行了分割分段(Segment)，每一把锁只锁容器其中一部分数据，多线程访问容器里不同数据段的数据，就不会存在锁竞争，提高并发访问率。（默认分配16个Segment，比Hashtable效率提高16倍。） 到了 JDK1.8 的时候已经摒弃了Segment的概念，而是直接用 Node 数组+链表+红黑树的数据结构来实现，并发控制使用 synchronized 和 CAS 来操作。（JDK1.6以后 对 synchronized锁做了很多优化） 整个看起来就像是优化过且线程安全的 HashMap，虽然在JDK1.8中还能看到 Segment 的数据结构，但是已经简化了属性，只是为了兼容旧版本；② Hashtable(同一把锁) :使用 synchronized 来保证线程安全，效率非常低下。当一个线程访问同步方法时，其他线程也访问同步方法，可能会进入阻塞或轮询状态，如使用 put 添加元素，另一个线程不能使用 put 添加元素，也不能使用 get，竞争会越来越激烈效率越低。 两者的对比图： HashTable: JDK1.7的ConcurrentHashMap： JDK1.8的ConcurrentHashMap（TreeBin: 红黑二叉树节点 Node: 链表节点）： 答：ConcurrentHashMap 结合了 HashMap 和 HashTable 二者的优势。HashMap 没有考虑同步，HashTable 考虑了同步的问题。但是 HashTable 在每次同步执行时都要锁住整个结构。 ConcurrentHashMap 锁的方式是稍微细粒度的。 ConcurrentHashMap 底层具体实现知道吗？实现原理是什么？ JDK1.7 首先将数据分为一段一段的存储，然后给每一段数据配一把锁，当一个线程占用锁访问其中一个段数据时，其他段的数据也能被其他线程访问。 在JDK1.7中，ConcurrentHashMap采用Segment + HashEntry的方式进行实现，结构如下： 一个 ConcurrentHashMap 里包含一个 Segment 数组。Segment 的结构和HashMap类似，是一种数组和链表结构，一个 Segment 包含一个 HashEntry 数组，每个 HashEntry 是一个链表结构的元素，每个 Segment 守护着一个HashEntry数组里的元素，当对 HashEntry 数组的数据进行修改时，必须首先获得对应的 Segment的锁。 该类包含两个静态内部类 HashEntry 和 Segment ；前者用来封装映射表的键值对，后者用来充当锁的角色；Segment 是一种可重入的锁 ReentrantLock，每个 Segment 守护一个HashEntry 数组里得元素，当对 HashEntry 数组的数据进行修改时，必须首先获得对应的 Segment 锁。 JDK1.8 在JDK1.8中，放弃了Segment臃肿的设计，取而代之的是采用Node + CAS + Synchronized来保证并发安全进行实现，synchronized只锁定当前链表或红黑二叉树的首节点，这样只要hash不冲突，就不会产生并发，效率又提升N倍。 结构如下： 如果该节点是TreeBin类型的节点，说明是红黑树结构，则通过putTreeVal方法往红黑树中插入节点；如果binCount不为0，说明put操作对数据产生了影响，如果当前链表的个数达到8个，则通过treeifyBin方法转化为红黑树，如果oldVal不为空，说明是一次更新操作，没有对元素个数产生影响，则直接返回旧值；如果插入的是一个新节点，则执行addCount()方法尝试更新元素个数baseCount； 辅助工具类 Array 和 ArrayList 有何区别？ Array 可以存储基本数据类型和对象，ArrayList 只能存储对象。Array 是指定固定大小的，而 ArrayList 大小是自动扩展的。Array 内置方法没有 ArrayList 多，比如 addAll、removeAll、iteration 等方法只有 ArrayList 有。 对于基本类型数据，集合使用自动装箱来减少编码工作量。但是，当处理固定大小的基本数据类型的时候，这种方式相对比较慢。 如何实现 Array 和 List 之间的转换？ Array 转 List： Arrays. asList(array) ；List 转 Array：List 的 toArray() 方法。 comparable 和 comparator的区别？ comparable接口实际上是出自java.lang包，它有一个 compareTo(Object obj)方法用来排序comparator接口实际上是出自 java.util 包，它有一个compare(Object obj1, Object obj2)方法用来排序 一般我们需要对一个集合使用自定义排序时，我们就要重写compareTo方法或compare方法，当我们需要对某一个集合实现两种排序方式，比如一个song对象中的歌名和歌手名分别采用一种排序方法的话，我们可以重写compareTo方法和使用自制的Comparator方法或者以两个Comparator来实现歌名排序和歌星名排序，第二种代表我们只能使用两个参数版的Collections.sort(). 方法如何比较元素？ TreeSet 要求存放的对象所属的类必须实现 Comparable 接口，该接口提供了比较元素的 compareTo()方法，当插入元素时会回调该方法比较元素的大小。TreeMap 要求存放的键值对映射的键必须实现 Comparable 接口从而根据键对元素进 行排 序。 Collections 工具类的 sort 方法有两种重载的形式， 第一种要求传入的待排序容器中存放的对象比较实现 Comparable 接口以实现元素的比较； 第二种不强制性的要求容器中的元素必须可比较，但是要求传入第二个参数，参数是Comparator 接口的子类型（需要重写 compare 方法实现元素的比较），相当于一个临时定义的排序规则，其实就是通过接口注入比较元素大小的算法，也是对回调模式的应用（Java 中对函数式编程的支持）。

Layout Go工程项目的整体组织 首先我们看一下整个 Go 工程是怎么组织起来的。 很多同事都在用 GitLab 的，GitLab 的一个 group 里面可以创建很多 project。如果我们进行微服务化改造，以前很多巨石架构的应用可能就拆成了很多个独立的小应用。那么这么多小应用，你是要建 N 个 project 去维护，还是说按照部门或者组来组织这些项目呢？在 B 站的话，我们之前因为是 Monorepo，现在是按照部门去组织管理代码，就是说在单个 GitLab 的 project 里面是有多个 app 的，每一个 app 就表示一个独立的微服务，它可以独立去交付部署。所以说我们看到下面这张图里面，app 的目录里面是有好多个子目录的，比方说我们的评论服务，会员服务。跟 app 同级的目录有一个叫 pkg，可以存放业务有关的公共库。这是我们的一个组织方式。当然，还有一种方式，你可以按照 GitLab 的 project 去组织，但我觉得这样的话可能相对要创建的 project 会非常多。 如果你按部门组织的话，部门里面有很多 app，app 目录怎么去组织？我们实际上会给每一个 app 取一个全局唯一名称，可以理解为有点像 DNS 那个名称。我们对业务的命名也是一样的，我们基本上是三段式的命名，比如账号业务，它是一个账号业务、服务、子服务的三段命名。三段命名以后，在这个 app 目录里面，你也可以按照这三层来组织。比如我们刚刚说的账号目录，我可能就是 account 目录，然后 VIP，在 VIP 目录下可能会放各种各样的不同角色的微服务，比方说可能有一些是做 job，做定时任务或者流式处理的一些任务，有可能是做对外暴露的 API 的一些服务，这个就是我们关于整个大的 app 的组织的一种形式。 微服务中的 app 服务分类 微服务中单个 app 的服务里又分为几类不同的角色。我们基本上会把 app 分为 interface（BFF）、service、job（补充：还有一个 task，偏向定时执行，job 偏向流式） 和 admin。 Interface 是对外的业务网关服务，因为我们最终是面向终端用户的 API，面向 app，面向 PC 场景的，我们把这个叫成业务网关。因为我们不是统一的网关，我们可能是按照大的业务线去独立分拆的一些子网关，这个的话可以作为一个对外暴露的 HTTP 接口的一个目录去组织它的代码，当然也可能是 gRPC 的（参考 B 站对外的 gRPC Moss 分享）。 Service 这个角色主要是面向对内通信的微服务，它不直接对外。也就是说，业务网关的请求会转发或者是会 call 我们的内部的 service，它们之间的通讯可能是使用自己的 RPC，在 b 站我们主要是使用 gRPC。使用 gRPC 通讯以后，service 它因为不直接对外，service 之间可能也可以相互去 call。 Admin 区别于 service，很多应用除了有面向用户的一些接口，实际上还有面向企业内部的一些运营侧的需求，通常数据权限更高，从安全设计角度需要代码物理层面隔离，避免意外。 第四个是 ecode。我们当时也在内部争论了很久，我们的错误码定义到底是放在哪里？我们目前的做法是，一个应用里面，假设你有多种角色，它们可能会复用一些错误码。所以说我们会把我们的 ecode 给单独抽出来，在这一个应用里面是可以复用的。注意，它只在这一个应用里面复用，它不会去跨服跨目录应用，它是针对业务场景的一个业务错误码的组织。 App 目录组织 我们除了一个应用里面多种角色的这种情况，现在展开讲一下具体到一个 service 里面，它到底是怎么组织的。我们的 app 目录下大概会有 api、cmd、configs、 internal 目录，目录里一般还会放置 README、CHANGELOG、OWNERS。 API 是放置 api 定义以及对应的生成的 client 代码，包含基于 pb 定义（我们使用 PB 作为 DSL 描述 API） 生成的 swagger.json。 而 cmd，就是放 main 函数的。Configs 目录主要是放一些服务所需的配置文件，比方说说我们可能会使用 TOML 或者是使用 YAML 文件。 Internal 的话，它里面有四个子目录，分别是 model、dao、service 和 server。Model 的定位职责就是对我们底层存储的持久化层或者存储层的数据的映射，它是具体的 Go 的一个 struct。我们再看 dao，你实际就是要操作 MySQL 或者 Redis，最终返回的就是这些 model（存储映射）。Service 组织起来比较简单，就是我们通过 dao 里面的各个方法来完成一个完整的业务逻辑。我们还看到有个 server，因为我一个微服务有可能企业内部不一定所有 RPC 都统一，那我们处于过渡阶段，所以 server 里面会有两个小目录，一个是 HTTP 目录，暴露的是 HTTP 接口，还有一个是 gRPC 目录，我们会暴露 gRPC 的协议。所以在 server 里面，两个不同的启动的 server，就是说一个服务和启动两个端口，然后去暴露不同的协议，HTTP 接 RPC，它实际上会先 call 到 service，service 再 call 到 dao，dao 实际上会使用 model 的一些数据定义 struct。但这里面有一个非常重要的就是，因为这个结构体不能够直接返回给我们的 api 做外对外暴露来使用，为什么？因为可能从数据库里面取的敏感字段，当我们实际要返回到 api 的时候，可能要隐藏掉一些字段，在 Java 里面，会抽象的一个叫 DTO 的对象，它只是用来传输用的，同理，在我们 Go 里面，实际也会把这些 model 的一些结构体映射成 api 里面的结构体（基于 PB Message 生成代码后的 struct）。 Rob Pike 当时说过的一句话，a little copying is better than a little dependency，我们就遵循了这个理念。在我们这个目录结构里面，有 internal 目录，我们知道 Go 的目录只允许这个目录里面的人去 import 到它，跨目录的人实际是不能直接引用到它的。所以说，我们看到 service 有一个 model，那我的 job 代码，我做一些定时任务的代码或者是我的网关代码有可能会映射同一个 model，那是不是要把这个 model 放到上一级目录让大家共享？对于这个问题，其实我们当时内部也争论过很久。我们认为，每一个微服务应该只对自己的 model 负责，所以我们宁愿去做一小部分的代码 copy，也不会去为了几个服务之间要共享这一点点代码，去把这个 model 提到和 app 目录级别去共用，因为你一改全错，当然了，你如果是拷贝的话，就是每个地方都要去改，那我们觉得，依赖的问题可能会比拷贝代码相对来说还是要更复杂的。 这个是一个标准的 PB 文件，就是我们内部的一个 demo 的 service。最上面的 package 是 PB 的包名，demo.service.v1，这个包使用的是三段式命名，全局唯一的名称。那这个名称为什么不是用 ID？我见过有些公司对内部做的 CMDB 或者做服务树去管理企业内部微服务的时候，是用了一些名称加上 ID 来搞定唯一性，但是我们知道后面那一串 ID 数字是不容易被传播或者是不容易被记住的，这也是 DNS 出来的一个意义，所以我们用绝对唯一的一个名称来表示这个包的名字，在后面带上这一个 PB 文件的版本号 V1。 我们看第二段定义，它有个 Service Demo 代码，其实就表示了我们这个服务要启动的服务的一个名称，我们看到这个服务名称里面有很多个 RPC 的方法，表示最终这一个应用或者这个 service 要对外暴露这几个 RPC 的方法。这里面有个小细节，我们看一下 SayHello 这个方法，实际它有 option 的一个选项。通过这一个 PB 文件，你既可以描述出你要暴露的是 gRPC 协议，又暴露出 HTTP 的一个接口，这个好处是你只需要一个 PB 文件描述你暴露的所有 api。我们回想一下，我们刚刚目录里面有个 api 目录，实际这里面就是放这一个 PB 文件，描述这一个工程到底返回的接口是什么。不管是 gRPC 还是 HTTP 都是这一个文件。还有一个好处是什么？实际上我们可以在 PB 文件里面加上很多的注释。用 PB 文件的好处是你不需要额外地再去写文档，因为写文档和写服务的定义，它本质上是两个步骤，特别容易不一致，接口改了，文档不同步。我们如果基于这一个 PB 文件，它生成的 service 代码或者调用代码或者是文档都是唯一的。 依赖顺序与 api 维护 就像我刚刚讲到的，model 是一个存储层的结构体的一一映射，dao 处理一些数据读写包，比方说数据库缓存，server 的话就是启动了一些 gRPC 或者 HTTP Server，所以它整个依赖顺序如下：main 函数启动 server，server 会依赖 api 定义好的 PB 文件，定义好这些方法或者是服务名之后，实际上生成代码的时候，比方说 protocbuf 生成代码的时候，它会把抽象 interface 生成好。然后我们看一下 service，它实际上是弱依赖的 api，就是说我的 server 启动以后，要注册一个具体的业务代码的逻辑，映射方法，映射名字，实际上是弱依赖的 api 生成的 interface 的代码，你就可以很方便地启动你的 server，把你具体的 service 的业务逻辑给注入到这个 server，和方法进行一一绑定。最后，dao 和 service 实际上都会依赖这个 model。 因为我们在 PB 里面定义了一些 message，这些 message 生成的 Go 的 struct 和刚刚 model 的 struct 是两个不同的对象，所以说你要去手动 copy 它，把它最终返回。但是为了快捷，你不可能每次手动去写这些代码，因为它要做 mapping，所以我们又把 K8s 里类似 DeepCopy 的两个结构体相互拷贝的工具给抠出来了，方便我们内部 model 和 api 的 message 两个代码相互拷贝的时候，可以少写一些代码，减少一些工作量。 上面讲的就是我们关于工程的一些 layout 实践。简单回溯一下，大概分为几块，第一就是 app 是怎么组织的，app 里面有多种角色的服务是怎么组织的，第三就是一个 app 里面的目录是怎么组织的，最后我重点讲了一下 api 是怎么维护的。 Unittest 测试方法论 现在回顾一下单元测试。我们先看这张图，这张图是我从《Google 软件测试之道》这本书里面抠出来的，它想表达的意思就是最小型的测试不能给我们的最终项目的质量带来最大的信心，它比较容易带来一些优秀的代码质量，良好的异常处理等等。但是对于一个面向用户场景的服务，你只有做大型测试，比方做接口测试，在 App 上验收功能的这种测试，你应用交付的信心可能会更足。这个其实要表达的就是一个“721 原则”。我们就是 70% 写小型测试，可以理解为单元测试，因为它相对来说好写，针对方法级别。20% 是做一些中型测试，可能你要连调几个项目去完成你的 api。剩下 10% 是大型测试，因为它是最终面向用户场景的，你要去使用我们的 App，或者用一些测试 App 去测试它。这个就是测试的一些简单的方法论。 单元测试原则 我们怎么去对待 Go 里面的单元测试？在《Google 软件测试之道》这本书里面，它强调的是对于一个小型测试，一个单元测试，它要有几个特质。它不能依赖外部的一些环境，比如我们公司有测试环境，有持续集成环境，有功能测试环境，你不能依赖这些环境构建自己的单元测试，因为测试环境容易被破坏，它容易有数据的变更，数据容易不一致，你之前构建的案例重跑的话可能就会失败。 我觉得单元测试主要有四点要求。第一，快速，你不能说你跑个单元测试要几分钟。第二，要环境一致，也就是说你跑测试前和跑测试后，它的环境是一致的。第三，你写的所有单元测试的方法可以以任意顺序执行，不应该有先后的依赖，如果有依赖，也是在你测试的这个方法里面，自己去 setup 和 teardown，不应该有 Test Stub 函数存在顺序依赖。第四，基于第三点，你可以做并行的单元测试，假设我写了一百个单元测试，一个个跑肯定特别慢。 doker-compose 最近一段时间，我们演进到基于 docker-compose 实现跨平台跨语言环境的容器依赖管理方案，以解决运行 unittest 场景下的容器依赖问题。 首先，你要跑单元测试，你不应该用 VPN 连到公司的环境，好比我在星巴克点杯咖啡也可以写单元测试，也可以跑成功。基于这一点，Docker 实际上是非常好的解决方式。我们也有同学说，其他语言有一些 in-process 的 mock，是不是可以启动 MySQL 的 mock ，然后在 in-process 上跑？可以，但是有一个问题，你每一个语言都要写一个这样的 mock ，而且要写非常多种，因为我们中间件越来越多，MySQL，HBase，Kafka，什么都有，你很难覆盖所有的组件 Mock。这种 mock 或者 in-process 的实现不能完整地代表线上的情况，比方说，你可能 mock 了一个 MySQL，检测到 query 或者 insert ，没问题，但是你实际要跑一个 transaction，要验证一些功能就未必能做得非常完善了。所以基于这个原因，我们当时选择了 docker-compose，可以很好地解决这个问题。 我们对开发人员的要求就是，你本地需要装 Docker，我们开发人员大部分都是用 Mac，相对来说也比较简单，Windows 也能搞定，如果是 Linux 的话就更简单了。本地安装 Docker，本质上的理解就是无侵入式的环境初始化，因为你在容器里面，你拉起一个 MySQL，你自己来初始化数据。在这个容器被销毁以后，它的环境实际上就满足了我们刚刚提的环境一致的问题，因为它相当于被重置了，也可以很方便地快速重置环境，也可以随时随地运行，你不需要依赖任何外部服务，这个外部服务指的是像 MySQL 这种外部服务。当然，如果你的单元测试依赖另外一个 RPC 的 service 的话，PB 的定义会生成一个 interface，你可以把那个 interface 代码给 mock 掉，所以这个也是能做掉的。对于小型测试来说，你不依赖任何外部环境，你也能够快速完成。 另外，docker-compose 是声明式的 API，你可以声明你要用 MySQL，Redis，这个其实就是一个配置文件，非常简单。这个就是我们在单元测试上的一些实践。 我们现在看一下，service 目录里面多了一个 test 目录，我们会在这个里面放 docker-compose 的 YAML 文件来表示这次单元化测试需要初始化哪些资源，你要构建自己的一些测试的数据集。因为是这样的，你是写 dao 层的单元测试的话，可能就需要 database.sql 做一些数据的初始化，如果你是做 service 的单元测试的话，实际你可以把整个 dao 给 mock 掉，我觉得反而还相对简单，所以我们主要针对场景就是在 dao 里面偏持久层的，利用 docker-compose 来解决。 容器的拉起，容器的销毁，这些工作到底谁来做？是开发同学自己去拉起和销毁，还是说你能够把它做成一个 Library，让我们的同学写单元测试的时候比较方便？我倾向的是后者。所以在我们最终写单元测试的时候，你可以很方便地 setup 一个依赖文件，去 setup 你的容器的一些信息，或者把它销毁掉。所以说，你把环境准备好以后，最终可以跑测试代码也非常方便。当然我们也提供了一些命令函，就是 binary 的一些工具，它可以针对各个语言方便地拉起容器和销毁容器，然后再去执行代码，所以我们也提供了一些快捷的方式。 刚刚我也提到了，就是我们对于 service 也好，API 也好，因为依赖下层的 dao 或者依赖下层的 service，你都很方便 mock 掉，这个写单元测试相对简单，这个我不展开讲，你可以使用 GoMock 或者 GoMonkey 实现这个功能。 Toolchain 我们利用多个 docker-compose 来解决 dao 层的单元测试，那对于我刚刚提到的项目的一些规范，单元测试的一些模板，甚至是我写了一些 dao 的一些占位符，或者写了一些 service 代码的一些占位符，你有没有考虑过这种约束有没有人会去遵循？所以我这里要强调一点，工具一定要大于约束和文档，你写了约束，写了文档，那么你最终要通过工具把它落实。所以在我们内部会有一个类似 go tool 的脚手架，叫 Kratos Tool，把我们刚刚说的约定规范都通过这个工具一键初始化。 对于我们内部的工具集，我们大概会分为几块。第一块就是 API 的，就是你写一个 PB 文件，你可以基于这个 PB 文件生成 gRPC，HTTP 的框架代码，你也可以基于这个 PB 文件生成 swagger 的一些 JSON 文件或者是 Markdown 文件。当然了，我们还会生成一些 API，用于 debug 的 client 方便去调试，因为我们知道，gRPC 调试起来相对麻烦一些，你要去写代码。 还有一些工具是针对 project 的，一键生成整个应用的 layout，非常方便。我们还提了 model，就是方便 model 和 DTO，DTO 就是 API 里面定义的 message 的 struct 做 DeepCopy，这个也是一个工具。 对于 cache 的话，我们操作 memcache，操作 Redis 经常会要做什么逻辑？假如我们有一个 cache aside 场景，你读了一个 cache，cache miss 要回原 DB，你要把这个缓存回塞回去，甚至你可能这个回塞缓存想异步化，甚至是你要去读这个 DB 的时候要做归并回源（singleflight），我们把这些东西做成一些工具，让它整个回源到 DB 的逻辑更加简单，就是把这些场景描述出来，然后你通过工具可以一键生成这些代码，所以也是会比较方便。 我们再看最后一个，就是 test 的一些工具。我们会基于项目里面，比方说 dao 或者是 service 定义的 interface 去帮你写好 mock 的代码，我直接在里面填，只要填代码逻辑就行了，所以也会加速我们的生产。 上图是 Kratos 的一个 demo，基本就是支持了一些 command。这里就是一个 kratos new kratos-demo 的一个工程，-d YourPath 把它导到某一个路径去，--proto 顺便把 API 里面的 proto 代码也生成了，所以非常简单，一行就可以很快速启动一个 HTTP 或者 gRPC 服务。 我们知道，一个微服务的框架实际非常重，有很多初始化的方式等等，非常麻烦。所以说，你通过脚手架的方式就会非常方便，工具大于约定和文档这个这个理念就是这么来的。 Configuration 讲完工具以后，最后讲一下配置文件。我为什么单独提一下配置文件？实际它也是工程化的一部分。我们一个线上的业务服务包含三大块，第一，应用程序，第二，配置文件，第三，数据集。配置文件最容易导致线上出 bug，因为你改一行配置，整个行为可能跟 App 想要的行为完全不一样。而且我们的代码的开发交付需要经过哪些流程？需要 commit 代码，需要 review，需要单元测试，需要 CD，需要交付到线上，需要灰度，它的整个流程是非常长的。在一步步的环境里面，你的 bug 需要前置解决，越前置解决，成本越低。因为你的代码的开发流程是这么一个 pipeline，所以 bug 最终流到线上的概率很低，但是配置文件没有经过这么复杂的流程，可能大家发现线上有个问题，决定要改个线上配置，就去配置中心或者配置文件改，然后 push 上线，接着就问题了，这个其实很常见。 从 SRE 的角度来说，导致线上故障的主因就是来自配置变更，所以 SRE 很大的工作是控制变更管理，如果能把变更管理做好，实际上很多问题都不会出现。配置既然在整个应用里面这么重要，那在我们整个框架或者在 Go 的工程化实践里面，我们应该对配置文件做一些什么事情？ 我觉得是几个。第一，我们的目标是什么？配置文件不应该太复杂，我见过很多框架，或者是业务的一些框架，它实际功能非常强大，但是它的配置文件超级多。我就发现有个习惯，只要有一个同事写错了这个配置，当我新起一个项目的时候，一定会有人把这个错误的配置拷贝到另外一个系统里面去。然后当发现这个应用出问题的时候，我们一般都会内部说一下，你看看其他同事有没有也配错的，实际这个配错概率非常高。因为你的配置选项越多，复杂性越高，它越容易出错。所以第一个要素就是说，尽量避免复杂的配置文件。配得越多，越容易出错。 第二，实际我们的配置方式也非常多，有些用 JSON，有些用 YAML，有些用 Properties，有些用 INI。那能不能收敛成通用的一种方式呢？无论它是用 Python 的脚本也好，或者是用 JSON 也好，你只要有一种唯一的约定，不需要太多样的配置方式，对我们的运维，对我们的 SRE 同时来说，他跨项目的变更成本会变低。 第三，一定要往简单化去努力。这句话其实包含了几个方面的含义。首先，我们很多配置它到底是必须的还是可选的，如果是可选，配置文件是不是就可以把它踢掉，甚至不要出现？我曾经有一次看到我们 Java 同事的配置 retry 有一个重试默认是零，内部重试是 80 次，直接把 Redis cluster 打故障了，为什么？其实这种事故很低级，所以简单化努力的另外一层含义是指，我们在框架层面，尤其是提供 SDK 或者是提供 framework 的这些同事尽量要做一些防御编程，让这种错配漏配也处于一个可控的范围，比方重试 80 次，你觉得哪个 SDK 会这么做？所以这个是我们要考虑的。但是还有一点要强调的是，我们对于业务开发的同事，我们的配置应该足够的简单，这个简单还包含，如果你的日志基本上都是写在这个目录，你就不要提供这个配置给他，反而不容易出错。但是对于我们内部的一些 infrastructure，它可能需要非常复杂的配置来优化，根据我的场景去做优化，所以它是两种场景，一种是业务场景，足够简单，一种是我要针对我的通用的 infrastructure 去做场景的优化，需要很复杂的配置，所以它是两种场景，所以我们要想清楚你的业务到底是哪一种形态。 还有一个问题就是我们配置文件一定要做好权限的变更和跟踪，因为我们知道上线出问题的时候，我们的第一想法不是查 bug，是先止损，止损先找最近有没有变更。如果发现有变更，一般是先回滚，回滚的时候，我们通常只回滚了应用程序，而忘记回滚了配置。每个公司可能内部的配置中心，或者是配置场景，或者跟我们的二进制的交付上线都不一样，那么这里的理念就是你的应用程序和配置文件一定是同一个版本，或者是某种意义上让他们产生一个版本的映射，比方说你的应用程序 1.0，你的配置文件 2.0，它们之间存在一个强绑定关系，我们在回滚的时候应该是一起回滚的。我们曾经也因为类似的一些不兼容的配置的变更，二进制程序上线，但配置文件忘记回滚，出现过事故，所以这个是要强调的。 另外，配置的变更也要经过 review，如果没问题，应该也是按照 App 发布一样，先灰度，再放量，再全量等等类似的一种方式去推，演进式的这种发布，我们也叫滚动发布，我觉得配置文件也是一样的思路。 加入阿里云钉钉群享福利：每周技术直播，定期群内有奖活动、大咖问答 原文链接

简介 ES是一个基于RESTful web接口并且构建在Apache Lucene之上的开源分布式搜索引擎。 同时ES还是一个分布式文档数据库，其中每个字段均可被索引，而且每个字段的数据均可被搜索，能够横向扩展至数以百计的服务器存储以及处理PB级的数据。 可以在极短的时间内存储、搜索和分析大量的数据。通常作为具有复杂搜索场景情况下的核心发动机。 ES就是为高可用和可扩展而生的。一方面可以通过升级硬件来完成系统扩展，称为垂直或向上扩展（Vertical Scale/Scaling Up）。 另一方面，增加更多的服务器来完成系统扩展，称为水平扩展或者向外扩展（Horizontal Scale/Scaling Out）。尽管ES能够利用更强劲的硬件，但是垂直扩展毕竟还是有它的极限。真正的可扩展性来自于水平扩展，通过向集群中添加更多的节点来分担负载，增加可靠性。ES天生就是分布式的，它知道如何管理多个节点来完成扩展和实现高可用性。意味应用不需要做任何的改动。 Gateway，代表ES索引的持久化存储方式。在Gateway中，ES默认先把索引存储在内存中，然后当内存满的时候，再持久化到Gateway里。当ES集群关闭或重启的时候，它就会从Gateway里去读取索引数据。比如LocalFileSystem和HDFS、AS3等。 DistributedLucene Directory，它是Lucene里的一些列索引文件组成的目录。它负责管理这些索引文件。包括数据的读取、写入，以及索引的添加和合并等。 River，代表是数据源。是以插件的形式存在于ES中。　 Mapping，映射的意思，非常类似于静态语言中的数据类型。比如我们声明一个int类型的变量，那以后这个变量只能存储int类型的数据。比如我们声明一个double类型的mapping字段，则只能存储double类型的数据。 Mapping不仅是告诉ES，哪个字段是哪种类型。还能告诉ES如何来索引数据，以及数据是否被索引到等。 Search Moudle，搜索模块，支持搜索的一些常用操作 Index Moudle，索引模块，支持索引的一些常用操作 Disvcovery，主要是负责集群的master节点发现。比如某个节点突然离开或进来的情况，进行一个分片重新分片等。这里有个发现机制。 发现机制默认的实现方式是单播和多播的形式，即Zen，同时也支持点对点的实现。另外一种是以插件的形式，即EC2。 Scripting，即脚本语言。包括很多，这里不多赘述。如mvel、js、python等。　　　 Transport，代表ES内部节点，代表跟集群的客户端交互。包括 Thrift、Memcached、Http等协议 RESTful Style API，通过RESTful方式来实现API编程。 3rd plugins，代表第三方插件。 Java(Netty)，是开发框架。 JMX，是监控。 使用案例 1、将ES作为网站的主要后端系统 比如现在搭建一个博客系统，对于博客帖子的数据可以直接在ES上存储，并且使用ES来进行检索，统计。ES提供了持久化的存储、统计和很多其他数据存储的特性。 注意：但是像其他的NOSQL数据存储一样，ES是不支持事务的，如果要事务机制，还是考虑使用其他的数据库做真实库。 2、将ES添加到现有系统 有些时候不需要ES提供所有数据的存储功能，只是想在一个数据存储的基础之上使用ES。比如已经有一个复杂的系统在运行，但是现在想加一个搜索的功能，就可以使用该方案。 3、将ES作为现有解决方案的后端部分 因为ES是开源的系统，提供了直接的HTTP接口，并且现在有一个大型的生态系统在支持他。比如现在我们想部署大规模的日志框架、用于存储、搜索和分析海量的事件，考虑到现有的工具可以写入和读取ES，可以不需要进行任何开发，配置这些工具就可以去运作。 设计结构 1、逻辑设计 文档 文档是可以被索引的信息的基本单位，它包含几个重要的属性： 是自我包含的。一篇文档同时包含字段和他们的取值。 是层次型的。文档中还可以包含新的文档，一个字段的取值可以是简单的，例如location字段的取值可以是字符串，还可以包含其他字段和取值，比如可以同时包含城市和街道地址。 拥有灵活的结构。文档不依赖于预先定义的模式。也就是说并非所有的文档都需要拥有相同的字段，并不受限于同一个模式 {   "name":"meeting",   "location":"office",   "organizer":"yanping" } {   "name":"meeting",   "location":{     "name":"sheshouzuo",        "date":"2019-6-28"   },   "memebers":["leio","shiyi"] } 类型 类型是文档的逻辑容器，类似于表格是行的容器。在不同的类型中，最好放入不同的结构的文档。 字段 ES中，每个文档，其实是以json形式存储的。而一个文档可以被视为多个字段的集合。 映射 每个类型中字段的定义称为映射。例如，name字段映射为String。 索引 索引是映射类型的容器一个ES的索引非常像关系型世界中的数据库，是独立的大量文档集合。   关系型数据库与ES的结构上的对比 2、物理设计 节点 一个节点是一个ES的实例，在服务器上启动ES之后，就拥有了一个节点，如果在另一个服务器上启动ES，这就是另一个节点。甚至可以在一台服务器上启动多个ES进程，在一台服务器上拥有多个节点。多个节点可以加入同一个集群。 当ElasticSearch的节点启动后，它会利用多播(multicast)(或者单播，如果用户更改了配置)寻找集群中的其它节点，并与之建立连接。这个过程如下图所示： 节点主要有3种类型，第一种类型是client_node，主要是起到请求分发的作用，类似路由。第二种类型是master_node，是主的节点，所有的新增，删除，数据分片都是由主节点操作（elasticsearch底层是没有更新数据操作的，上层对外提供的更新实际上是删除了再新增），当然也能承担搜索操作。第三种类型是date_node，该类型的节点只能做搜索操作，具体会分配到哪个date_node，就是由client_node决定，而data_node的数据都是从master_node同步过来的 分片 一个索引可以存储超出单个结点硬件限制的大量数据。比如，一个具有10亿文档的索引占据1TB的磁盘空间，而任一节点都没有这样大的磁盘空间；或者单个节点处理搜索请求，响应太慢。   为了解决这个问题，ES提供了将索引划分成多份的能力，这些份就叫做分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。 分片之所以重要，主要有两方面的原因：   1、允许你水平分割/扩展你的内容容量 允许你在分片（潜在地，位于多个节点上）之上进行分布式的、并行的操作，进而提高性能/吞吐量 至于一个分片怎样分布，它的文档怎样聚合回搜索请求，是完全由ES管理的，对于作为用户的你来说，这些都是透明的。   2、在一个网络/云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了。这种情况下，有一个故障转移机制是非常有用并且是强烈推荐的。为此目的，ES允许你创建分片的一份或多份拷贝，这些拷贝叫做复制分片，或者直接叫复制。 复制之所以重要，主要有两方面的原因： （1）在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要（original/primary）分片置于同一节点上是非常重要的。 （2）扩展你的搜索量/吞吐量，因为搜索可以在所有的复制上并行运行 总之，每个索引可以被分成多个分片。一个索引也可以被复制0次（意思是没有复制）或多次。一旦复制了，每个索引就有了主分片（作为复制源的原来的分片）和复制分片（主分片的拷贝）之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可以在任何时候动态地改变复制数量，但是不能改变分片的数量。   默认情况下，ES中的每个索引被分片5个主分片和1个复制，这意味着，如果你的集群中至少有两个节点，你的索引将会有5个主分片和另外5个复制分片（1个完全拷贝），这样的话每个索引总共就有10个分片。一个索引的多个分片可以存放在集群中的一台主机上，也可以存放在多台主机上，这取决于你的集群机器数量。主分片和复制分片的具体位置是由ES内在的策略所决定的。 3、插件HEAD elasticsearch-head是一个界面化的集群操作和管理工具 ● node：即一个 Elasticsearch 的运行实例，使用多播或单播方式发现 cluster 并加入。 ● cluster：包含一个或多个拥有相同集群名称的 node，其中包含一个master node。 ● index：类比关系型数据库里的DB，是一个逻辑命名空间。 ● alias：可以给 index 添加零个或多个alias，通过 alias 使用index 和根据index name 访问index一样，但是，alias给我们提供了一种切换index的能力，比如重建了index，取名● customer_online_v2，这时，有了alias，我要访问新 index，只需要把 alias 添加到新 index 即可，并把alias从旧的 index 删除。不用修改代码。 ● type：类比关系数据库里的Table。其中，一个index可以定义多个type，但一般使用习惯仅配一个type。 ● mapping：类比关系型数据库中的 schema 概念，mapping 定义了 index 中的 type。mapping 可以显示的定义，也可以在 document 被索引时自动生成，如果有新的 field，Elasticsearch 会自动推测出 field 的type并加到mapping中。 ● document：类比关系数据库里的一行记录(record)，document 是 Elasticsearch 里的一个 JSON 对象，包括零个或多个field。 ● field：类比关系数据库里的field，每个field 都有自己的字段类型。 ● shard：是一个Lucene 实例。Elasticsearch 基于 Lucene，shard 是一个 Lucene 实例，被 Elasticsearch 自动管理。之前提到，index 是一个逻辑命名空间，shard 是具体的物理概念，建索引、查询等都是具体的shard在工作。shard 包括primary shard 和 replica shard，写数据时，先写到primary shard，然后，同步到replica shard，查询时，primary 和 replica 充当相同的作用。replica shard 可以有多份，也可以没有，replica shard的存在有两个作用，一是容灾，如果primary shard 挂了，数据也不会丢失，集群仍然能正常工作；二是提高性能，因为replica 和 primary shard 都能处理查询。另外，如上图右侧红框所示，shard数和replica数都可以设置，但是，shard 数只能在建立index 时设置，后期不能更改，但是，replica 数可以随时更改。但是，由于 Elasticsearch 很友好的封装了这部分，在使用Elasticsearch 的过程中，我们一般仅需要关注 index 即可，不需关注shard。   shard、node、cluster 在物理上构成了 Elasticsearch 集群，field、type、index 在逻辑上构成一个index的基本概念，在使用 Elasticsearch 过程中，我们一般关注到逻辑概念就好，就像我们在使用MySQL 时，我们一般就关注DB Name、Table和schema即可，而不会关注DBA维护了几个MySQL实例、master 和 slave 等怎么部署的一样。 ES中的索引原理 （1）传统的关系型数据库 二叉树查找效率是logN，同时插入新的节点不必移动全部节点，所以用树型结构存储索引，能同时兼顾插入和查询的性能。因此在这个基础上，再结合磁盘的读取特性(顺序读/随机读)，传统关系型数据库采用了B-Tree/B+Tree这样的数据结构做索引 （2）ES 采用倒排索引 那么，倒排索引是个什么样子呢？ 首先，来搞清楚几个概念，为此，举个例子： 假设有个user索引，它有四个字段：分别是name，gender，age，address。画出来的话，大概是下面这个样子，跟关系型数据库一样 Term（单词）：一段文本经过分析器分析以后就会输出一串单词，这一个一个的就叫做Term Term Dictionary（单词字典）：顾名思义，它里面维护的是Term，可以理解为Term的集合 Term Index（单词索引）：为了更快的找到某个单词，我们为单词建立索引 Posting List（倒排列表）：倒排列表记录了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息，每条记录称为一个倒排项(Posting)。根据倒排列表，即可获知哪些文档包含某个单词。（PS：实际的倒排列表中并不只是存了文档ID这么简单，还有一些其它的信息，比如：词频（Term出现的次数）、偏移量（offset）等，可以想象成是Python中的元组，或者Java中的对象） （PS：如果类比现代汉语词典的话，那么Term就相当于词语，Term Dictionary相当于汉语词典本身，Term Index相当于词典的目录索引） 我们知道，每个文档都有一个ID，如果插入的时候没有指定的话，Elasticsearch会自动生成一个，因此ID字段就不多说了 上面的例子，Elasticsearch建立的索引大致如下： name字段： age字段： gender字段： address字段： Elasticsearch分别为每个字段都建立了一个倒排索引。比如，在上面“张三”、“北京市”、22 这些都是Term，而[1，3]就是Posting List。Posting list就是一个数组，存储了所有符合某个Term的文档ID。 只要知道文档ID，就能快速找到文档。可是，要怎样通过我们给定的关键词快速找到这个Term呢？ 当然是建索引了，为Terms建立索引，最好的就是B-Tree索引（MySQL就是B树索引最好的例子）。 我们查找Term的过程跟在MyISAM中记录ID的过程大致是一样的 MyISAM中，索引和数据是分开，通过索引可以找到记录的地址，进而可以找到这条记录 在倒排索引中，通过Term索引可以找到Term在Term Dictionary中的位置，进而找到Posting List，有了倒排列表就可以根据ID找到文档了 （PS：可以这样理解，类比MyISAM的话，Term Index相当于索引文件，Term Dictionary相当于数据文件） （PS：其实，前面我们分了三步，我们可以把Term Index和Term Dictionary看成一步，就是找Term。因此，可以这样理解倒排索引：通过单词找到对应的倒排列表，根据倒排列表中的倒排项进而可以找到文档记录） 为了更进一步理解，用两张图来具现化这一过程： （至于里面涉及的更加高深的数据压缩技巧，以及多个field联合查询利用跳表的数据结构快速做运算来查询，这些大家有兴趣可以自己去了解）