《设计人的面试记录》专题

整体设计 在整个CAT从开发至今，一直秉承着简单的架构就是最好的架构原则，整个CAT主要分为三个模块，cat-client，cat-consumer，cat-home。 cat-client 提供给业务以及中间层埋点的底层sdk。 cat-consumer 用于实时分析从客户端的提供的数据。 cat-home 作为用户提供给用户的展示的控制端。 在实际开发和部署中，cat-consumer和cat

1.1 设计初衷 大众点评最开始采用F5做七层负载。随着网站规模的增大，F5成为了网络的瓶颈，主要原因有以下两点： 负载规则涉及到很多路径的正则匹配，这要求F5做很多的正则计算。这大大增加了F5的CPU负载。 F5需要对业务服务集群进行心跳检测。随着业务服务规模增大，F5需要对近千台服务器进行心跳检测。F5很难维持这个量级的心跳信息。 为此，我们决定使用软件工程的银弹－在架构上，增加新的层级。从而

适用场景 最终一致 单向同步 实现依据 MQ消息顺序消费 MQ消息组内消息最多被消费一次 仅支持DML，DDL、DCL手工执行 表必须有主键、最后更新时间 系统架构 Node节点内存模型 TaskController 1---* TaskWorker TaskWorker 1---* TaskWork TaskWork 1---1 *Job 通俗上讲TaskController对应Node进程，进

YDoc 项目设计规范 YDoc 的设计稿经过设计师的几度推敲重做，诞生了现在你看到的默认主题，YDoc 有如下设计理念： 青春：使用大胆、活泼的配色方案，体现 YMFE 团队 的产品文化 科学：以科学的态度对待视觉设计、功能设计，让设计有迹可循 简洁：以 无形 代替 有形，从 UI 到开发体验，不断去除冗余的设计，使用户专注于写作与阅读 以下是 YDoc 设计过程中总结的一些规则，这些可以帮助你

设计思路 实行一个进程调度策略，到底需要实现哪些基本功能对应的数据结构？首先考虑到一个无论哪种调度算法都需要选择一个就绪进程来占用CPU运行。为此我们可把就绪进程组织起来，可用队列（双向链表）、二叉树、红黑树、数组…等不同的组织方式。 在操作方面，如果需要选择一个就绪进程，就可以从基于某种组织方式的就绪进程集合中选择出一个进程执行。需要注意，这里“选择”和“出”是两个操作，选择是在集合中挑选一个“

设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。 设计模式并不直接用来完成代码的编写，而是描述在各种不同情况下，要怎么解决问题的一种方案。面向对象设计模式通常以类或对象来描述其中的关系和相互作用，但不涉及用来完成应用程序的特定类或对象。设计模式能使不稳定依赖于相对稳定、具体依赖于相对抽象，避免会引起麻烦的紧耦合，以增强软件设计面对并适应变化的能力。 目录 创建型 ​构造函数

在了解了项目基本的结构划分以后，我们将要开始设计 model，在设计 model 之前，我们来回顾一下我们需要做的项目是什么样的： Model 的抽象 从设计稿中我们可以看出，这部分功能基本是围绕 以用户数据为基础 的操作，其中包含： 用户信息的展示（查询） 用户信息的操作（增加，删除，修改） 有经验的同学不难发现，无论是多复杂的项目也基本上是围绕着数据的展示和操作，复杂一点的无非是组合了很多数据

接口设计 用户使用 Web 客户端访问 Web 系统，系统在收到请求后执行操作 （收集数据模型，选择数据经行组装），将结果返回给客户。 其中包括的元素和关系如下图所示： Template，分离数据模型的页面结构，根据不同的数据模型展现不同的信息 URL，页面访问地址、页面标示 API，用于载入异步请求的接口 Model，数据模型，页面模板组装模型和异步请求返回的数据模型 约定 URL 与页面模板间

Angel的设计理念 Angel的整体设计理念，是简约而不简单，做一个灵活而强大的参数服务器，并在此之上，提供多种机器学习算法，和PS服务，扩展为一个分布式机器学习平台。 因此，在开发之时，Angel从如下5个方向，对整体进行了改进和设计，并在它们之间进行了平衡。包括： 易用性 灵活性 性能 可扩展性 稳定性 另外，Angel设计之初，并没有特地为深度学习量身定做，但随着深度学习日趋流行，而PS模

Angel的架构设计 Angel的整体设计比较简约，层次鲜明，容易上手，没有过多复杂的设计，关注模型和机器学习相关特性，追求高维度模型下的最佳性能。它的架构设计，从整体可以分为3大模块： Parameter Server层：提供通用的参数服务器服务，负责模型的分布存储，通讯同步和协调计算，并通过PSAgent提供PS Service Worker层： 基于Angel自身模型设计的分布式运行节点，自

账户模型与 UTXO 比特币，及其很多的继任者，将用户的余额存储在一个基于 UTXO（unspent transaction output）的数据结构中，系统的整个状态由一个“未花费输出，unspent output” 的集合构成。那么 UTXO 到底是什么呢？简单来说，UTXO 就是人民币，就是 “coin”。有多少 UTXO，就有多少人民币。跟人民币的区别在于： “面值”，人民币的面值有 1

这一章将介绍 Kubernetes 的设计理念及基本概念。 Kubernetes设计理念与分布式系统 分析和理解Kubernetes的设计理念可以使我们更深入地了解Kubernetes系统，更好地利用它管理分布式部署的云原生应用，另一方面也可以让我们借鉴其在分布式系统设计方面的经验。 分层架构 Kubernetes设计理念和功能其实就是一个类似Linux的分层架构，如下图所示 核心层：Kubern

任何优秀的项目都离不开优秀的架构设计。本小节将介绍 Kubernetes 在架构方面的设计考虑。 基本考虑 如果让我们自己从头设计一套容器管理平台，有如下几个方面是很容易想到的： 分布式架构，保证扩展性； 逻辑集中式的控制平面 + 物理分布式的运行平面； 一套资源调度系统，管理哪个容器该分配到哪个节点上； 一套对容器内服务进行抽象和 HA 的系统。 运行原理 下面这张图完整展示了 Kubernet

设计模式

导航栏 uniapp可以通过配置pages.json生成原生元素的导航栏，简要说明如下： 优点是可以快速渲染，配置便捷，还可以带入一部分原生内容(针对App Store) 缺点是配置不够灵活，遮罩无法覆盖导航栏等 建议： 如果开发者使用nuve，可以直接自定义导航栏，无需使用uniapp自带的 如果是普通的vue页面，直接使用uniapp自带导航栏。如果自带的不能满足，条件允许就用subNVue绘