About

欢迎访问KTSee.eu.org，这里记录与分享一些有用的信息，如有任何疑问，你可以通过blogger@ktsee.eu.org联系到我，谢谢。

此博客中的热门博文

如何去做code review

Google 前几天公开了一篇谷歌的工程实践文档。而且文档的内容都是跟 code review 相关的内容，里面包含了 Google 工程师如何进行 code review 的内容，以及 code review 指南。 原文地址: google.github.io/eng-practic… 本文的名词解释： cr: code review cl: change list，指这次改动 reviewer: cr的那个review人 nit: 全称nitpick，意思是鸡蛋里挑骨头 作者: 也就是本次CL的开发者，原文中是以author来称开发者的。以老外的思维，意思是“CL的作者” 如果嫌文章太长，可以直接到 后面 看总结 cr的标准 cr(Code review)主要目的在于确保Google 的代码库代码质量越来越好。而所有相关的工具与流程皆是因应这个目的而生。为达到此目的，势必需要做出一连串的权衡与取舍 首先，开发人员必须能够在自己负责的任务上有所进展。如果你从来没有向代码库提交改进过的代码，那么代码库就永远不会改进。另外，如果一个reviewer使cr都很难进行的话，那么开发人员就不愿意在将来进行改进。 另一方面，reviewer有责任确保每个change list（ 下称CL ）的质量，保证其代码库的整体代码质量不会越来越差。这可能很棘手，因为通常会随着时间的推移，代码需要降级才能让代码运行起来，特别是当团队受到严重的时间限制时，大家觉得必须走捷径才能实现他们的目标。 此外，reviewer对他们正在review的代码拥有所有权和责任。他们希望确保代码保持一致、可维护，以及下文的“ 在cr中可以得到什么 ”中提到的内容。 因此，我们有以下规则，作为我们在cr中所期望的标准： 一般来说，当CL存在的时候，reviewer应该赞成它，此时它肯定会提高正在工作的系统的整体代码质量，即使这个CL并不完美。这是所有cr中的首要原则。当然，这是有局限性的。例如，如果一个CL添加了一个reviewer不希望在其系统中使用的功能，那么reviewer当然可以拒绝，即使代码设计得很好。 这里的一个关键点是，没有“完美”的代码，只有更好的代码。reviewer不应该要求作者在approve之前对一篇文章的每一小段进行润色。相反，revie...
阅读全文

kubernetes中部署mysql高可用集群

很多软件后端使用的存储都是mysql，当这些软件系统在生产环境部署时，都会面临一个严峻问题，需要在生产环境中部署一个高可用的mysql集群服务。刚好在最近一周的工作中，需要在kubernetes环境中搭建mysql高可用集群，这里记录一下。 搭建MySQL集群 MySQL的主从半同步复制方案、Galera集群方案以前都也实践过，感觉都不是太友好，配置比较麻烦，而且发生故障转移时经常需要人工参与。所以这里还是采用MySQL官方推荐的Group Replication集群方案。关于MySQL Group Replication集群的架构设计可以看 官方文档 ，懒得看英文的话，也可以看我之前整理出的 资料 。另外kubedb网页上也有介绍 MySQL几种高可用方案的构架方案 ，也比较有意思。 之前的博文 也讲过在非容器环境搭建MySQL Group Replication集群，现在在Kubernetes的容器环境配合kubedb，搭建更方便了，命令如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 # 添加appscode的helm仓库 $ helm repo add appscode https://charts.appscode.com/stable/ $ helm repo update # 部署kubedb $ helm install appscode/kubedb --namespace kube-system --name kube...
阅读全文

Inf-- kafka 从入门到放弃

概述 工作中用到了kafka ,本篇博文整理一下学习到的kafka相关知识，内容多来自网上（主要是官网doc,个人博客），侵删。 kafka 是Linkedin 使用Scala 编写的一个开源的分布式消息系统，当时开发的初衷是为了解决网站活动流数据（比如网页浏览，点击，驻留时间等等）的数据转发处理。因为活动流数据是实时且流量比较大，可想而知kafka 的最大特点就是高吞吐率且容易扩展。 kafka 的设计目标如下： 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。 支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。 同时支持离线数据处理和实时数据处理。 Scale out：支持在线水平扩展。 使用场景 从不同的角度出发，kafka的作用也不同。 kafka作为一个消息系统，类比redis,rabbitmq等同类产品， kafka作为一个存储系统，因为进入kafak的消息都会被持久化所以可以作为一个存储系统， kafka作为一个流处理系统，对于流数据，可以在kafka里多次处理，多次流转。 相应的，kafka 的使用场景大致如下： 作为传统消息队列系统的替换。 做metric监控数据的收集处理。 做日志数据的收集处理。 流数据处理。 事件驱动架构的核心组件。 上图中可看出kafka的角色，相应的，kafka也提供了四种核心api: The Producer API allows an application to publish a stream of records to one or more Kafka topics. The Consumer API allows an application to subscribe to one or more topics and process the stream of records produced to them. The Streams API allows an application to act as a stream processor, consuming an input stream...
阅读全文

部署教程 利用Google Drive 和 CloudFlare 做索引网盘

功能 部署在 CloudFlare Workers的小程序。 可以将 Google Drive 文件以目录形式列出，并直连下载。 流量走 CloudFlare ，网速由 CloudFlare 决定。 开源仓库 GitHub: https://github.com/donwa/goindex 示例 https://index.gd.workers.dev/ 安装运行 1、访问 https://install.gd.workers.dev/ 2、授权认证后，生成部署代码。 3、复制代码 到 CloudFlare 部署。 特点 1、免费。 2、直链。 3、免番。 使用限制 wokers一天10万请求限制 google drive 下载10T/24h（大佬说的） google api 调用限制 部署步骤 1）访问 https://install.gd.workers.dev/ 点击 【1.获取认证码】登陆Google帐号，会有code(画线部分）。 将上面的CODE复制到 Auth认证码部分。目录ID可以留空！ 2）点【2.生成代码】 复制生成的代码，打开 https://dash.cloudflare.com/ 登陆帐号，选个域名，点击 Workers，如图 3）点击 new Workers dashboard 如图，需要起个名字，我已经起过了，就没有截图了 类似与 qwe.workers.dev的名字 只能修改前缀，后缀workers.dev 固定的。 4）点击Create a Workers，如图， 5）在Script里复制刚才的代码code，右下角Run可以在右边看到浏览状态 右边上方有地址，左边上方可以修改地址，例如修改为121，Save and Deploy保存 121.qwe.workers.dev 就是你的地址了。 其他内容 如何自定义域名 1）先让需要绑定的域名通过cf，指向ip随意。 2）添加Route 关于目录ID 打开团队盘(或文件夹或别人共享的文件夹)，看地址栏。 https://drive.google.com/drive/folders/ {这后面一堆代码就是id} 留空是根目录。  来源： http...
阅读全文

项目管理标准模板

 之前写了一篇 《技术管理标准模板》 ，其中项目管理部分并没有具体深入，而这一技能不仅仅是对于技术Leader的要求，从我的经验看来，只要是程序员，具有项目管理能力都是如虎添翼的，即使你走的是专业路线。本文即基于自己的经验，从项目的启动和迭代阶段总结了敏捷项目管理的一些标准动作。 启动阶段 相关干系人沟通，同步项目背景、业务价值等 启动会议：召集相关干系人，明确业务相关信息，确定相关流程制度等 需求收集和分析-> 总体需求文档 ，概括性的功能与非功能需求列表 初步的产品规划-> 每一轮迭代的需求列表、发布时间 创建项目基础设施-> 可持续交付到测试环境的基础项目 ，包括各个端的代码库、到测试环境的流水线等。 迭代阶段 两周为一迭代，包括需求、设计、开发、测试、发布。关键点在于需求的拆分、优先级以及并行化。 1. 需求评审 对本轮迭代的需求尽心评审确认。 前置条件 ：产品经理对此轮迭代进行需求确认，产出需求条目，按 优先级 排列；需求需要拆的足够小，把大需求拆成一个个 能够独立开发测试发布 的小需求 2. 工作规划 根据本轮迭代需求做WBS任务分解 WBS工作项分解: 甘特图 里程碑结点: 表格或者里程碑图 风险管理：风险点预估、严重程度、可能性、应对措施 3. 设计/技术评审 分别对交互设计和技术设计进行评审 前置条件 ：设计师需要输出设计图；技术部分做概要设计和系统设计，随着每一轮迭代进行更新维护 4. 测试用例评审 由QA安排，会前需要提前将测试用例文档发给产品经理与研发，提前标注有疑问的用例。 5. 开发、测试过程的监控 持续交付：开发和迭代测试，需求开发完成后即测试并进行缺陷跟踪。 会议 每日站会：全员站会，了解整体状况，对暴露出的风险和问题作出集体决策。 项目周会：10人以上团队。解决整体计划层面、跨团队协同配合的问题。 项目周报 汇总项目总体状况，回答三个问题 项目的整体进展状态到底如何？ 风险可控吗？ 目标达成有没有问题？ 6. 版本全量测试 对所有已经开发完的功能进行交叉测试、全量测试、埋点测试、回归测试、第三方云测。 7. 验包发布 此迭代所有功能开发测试完成后，提交审核流程，各流程审核人验收通过后发布。 ...
阅读全文

微信小程序小总结

微信小程序使用起来感觉像写h5一样，对于新手估计会有比较多疑惑，如果撇去这些想法应该是很快就能上手的一套开发方案。 但是它自身的限制也比较大，如不提供window对象会导致一些功能实现起来比较麻烦。我这次开发的小程序就遇到了，虽然比较快找到解决办法（可能都是比较标准化的东西），希望之后不会有其他大坑。 需要其实比较简单，就是两页文章列表及文章详情页，刚上手却遇到下面的坑： 无法利用window对象解析xml 不支持HTML标签的使用 怎样兼容Promise和generator异步 刚开始一脸懵逼...后来赶紧去github看看各大牛例子及一些工具就解决了。 解析xml问题 由于比较多的解析插件都是基于 window.DOMParser 处理的，在小程序却无用武之地。找到问题就好解决，我要的是 DOMParser 而不是window找找应该有代替品，然后找到这个 xmldom 引入代替掉 DOMParser 就解决，然后把xml转成json处理了。 评论有问道如何改，这里我已经把这个整合到 这库 了。 解析html问题 现在比较成熟的是 wxParse 这货，的确大部分的html标签均能解析渲染，但是我这边程序录入的富文本内容却掺杂了些奇奇怪怪的标签，解析时还是会出错，内容解析到一半就停了...既然它做不到忽略，咋整？那把那些垃圾都过滤掉吧！！！马上用上 js-xss 这个来处理问题，能控制过滤的标签及标签能拥有的属性，方便得很。 const xss = require ( '../lib/js-xss/xss' ) const WxParse = require ( '../../lib/wxParse/wxParse.js' ) //把style及class添加到白名单。 Object .keys(xss.whiteList).forEach( name => xss.whiteList[name] = xss.whiteList[name].concat([ 'style' , 'class' ])) let content = xss( '<div>HTML文本</div>' , ...
阅读全文

ThinkPad E480 黑苹果踩坑和黑苹果常用操作备忘

由于囊中羞涩，只好一部 ThinkPad 商务本凑合一年有余。最近赋闲在家无事可干，打算更新一下开发环境。Windows 搭配 Cygwin 的选择毫无疑问被排除在外、WSL 的 IO 性能无法直视、开源拖拉机 Linux 的生态一时半会无法适应。想来想去，不如装个黑苹果（Hackintosh）过把用 macOS 的瘾。 本文前半部分会记录我在 ThinkPad E480 上踩过的几个坑和解决方法，后半部分则是我自己备忘的黑苹果的相关知识。 我不是专业安装黑苹果的玩家， 在短期内   我也不会考虑开源我的 EFI。   EFI 已使用 Unlicense 开源协议在 GitHub， 地址 。 ThinkPad 黑苹果无线网卡 ThinkPad E480 出厂时搭载的无线网卡是   Realtek 8821CE Wireless LAN 802.11ac PCI-E NIC ，目前没有办法驱动。 目前最好的选择是换装   DW1560 ，在 macOS 下毫不费力就可以驱动，在 Windows 下也能轻易驱动。不推荐用   DW1820A ，在 ThinkPad 系列机型上都需要屏蔽识别针脚、在系统中容易引发冻屏。而且   DW1820A   有的批次可以轻易驱动、有的则难如登天。如果你执意要趟坑   DW1820A ，请参考   黑果小兵的这篇文章 。 AppleALC 驱动声卡 ThinkPad E480 的内置的声卡是相对罕见的   Conexant CX20753/4 。但是好消息是， MacPeet   为 AppleALC 添加了   CX20753/4   支持（ layout-id: 15 ），而且 MacPeet 的机型是 ThinkPad E580、是 ThinkPad E480 的姊妹机型。在实际测试中， layout-id   取   3   或者   15   都可以驱动 ThinkPad E480 的声卡，3.5mm 耳机接口和外放都可以正常使用。 触摸板、键盘、ThinkPad 小红点驱动 建议使用   Rehabman 版本的 VoodooPS2Con...
阅读全文

Blogger 国内访问心得

谨以此篇记下我的这几天来的折腾。首先申明，我是一个外行，倒腾的东西可能不入您的法眼，这也无可厚非。不过我想这篇文章应该能对一些想用 Blogger 写博客的人带来帮助。 一、为什么用 Blogger？ Google 在全球各地的数据中心能够保证一流的访问速度 免费使用，免备案，无审查 可以添加 Google 广告 Blogger 模板自定义程度高 自定义第三方域名后，可实现国内访问 只需要一个域名，再对博客模板进行国内访问优化，我们就可以开始 Blogger 之旅了。 Blogger 的缺点 不过在此，我要多说一句，Blogger 国内访问使用的 IP 有可能经常被墙，所以使用过程，少不了一些折腾。目前我所认识的使用 Blogger 的博主们的网站还算稳定。 现在我已经使用快两年了，IP 一直很稳，至少在我这边，访问速度非常快。且，如果 Blogger 服务器 IP 都被墙了，我们还有两种方法让博客继续访问。 使用 Cloudflare CDN 使用服务器反向代理 Blogger 还有一个缺点，如果你想给你的博客加上一些功能的话。 你得去学习 Blogger 模板的特定语法； 你可能要学习 Javascript 的基本知识。 所以，如果你想要加入 Blogger，请先想一想其中的优缺点再做决定。 二、国内使用 Blogger 攻略 首先，请确认自己能够科学上网。 1. 域名 当你用 Blogger 创建一个博客时，你会得到一个 xxxx.blogspot.com 的二级域名，因为 blogspot.com 已经被墙了，所以我们仅仅是这样，是不能访问自己的博客的。好在，Blogger 允许我们绑定第三方域名，绑定之后，我们就可以在国内访问自己的博客了。 ① 怎么操作呢？ 在「设置-基本-发布-博客地址」中添加「第三方网域」，即可。 ② 域名去哪里买呢？ 这个时候，你就需要拥有一个域名了。域名购买是你使用 Blogger，唯一需要花费的事项。 ③ 怎么选择一个合适的域名？ 域名如何选择，当然是看你自己喜欢。不过，我的建议是——简洁优雅易记。另外，推荐你一个挑选域名的好网站： NameBeta 。它的优点有二：快速查询，域名比价。 2. 域名解析设置 购得域名，就需要在 Blo...
阅读全文

高可用用户中心设计

概述 我们公司现在的账户体系比较混乱，每个系统都有一套自己的账户体系，没有办法进行统一的账户管理，比如统计一个人在哪个系统有账号，这样操作是比较麻烦的，还有就是我们如何进行用户行为分析，最终综合用户的信息进行用户的画像。这些都是需要解决的问题。 常规的用户设计是统一账号和统一登录验证，统一注册等信息。但是结合我们公司的实际，发现这样的话我们的系统可能会出问题，我们无法屏蔽很多细节。我们的现状是： 系统需要向用户隐藏是同一个公司的这个事实。也就是说我们做了用户中心的设计，但是不能让用户感知这个系统的存在。也就是说多个系统之间的登录都是需要隔离的。离论上不能做统一账号的登录，但是可以做统一账号的验证。 同一个系统可能有多个马甲app，我想马甲app之间也需要登录隔离，虽然他们调用的是同一个后台系统，那么我们不得不面对一个问题，同一个用户同时下单的逻辑处理，需要后台做这种处理，否则就会出现严重的并发错误，而开发人员可能都没有注意到这个事实的存在，从而导致一些稀奇古怪的事情出现。 web端与app端应该是需要同时登录的，我们好像没有web的要求，但是好像有微信的web端的事情。假如我们有web端的登录，那么问题来了，我们要不要实现二维码登录web。目前看是可以先不实现的，但是作为设计考量我们不得不考虑这些。 第三方账户的登录，我们是通过手机号作为唯一标识，那么不太好实现第三方的登录注册。但是我们可以后期实现，如果实现第三方的登录注册，那么问题来了，我们的设计貌似不支持，需要改动，就是改掉手机作为唯一标识的问题，但是想想好像是不影响的，只要数据能插入问题就不大，因为没有手机号，这些用户是不能登录需要手机的app，但是有的系统可以做特殊处理，从而支持第三方账户的登录注册。但是这样做也有缺点，就是用户利用多种方式进行注册，也就是说我们不得不解决一个问题就是用户可能存在多个账户的可能性。加入用户有微信注册的账户，然后又用手机登录，绑定微信，这个时候我们可能需要去系统中用微信的unionId或者openId查找一下是否有用户，有就不能绑定，没有才能绑定。如果有我们可能也知道了这个人有重复号的可能性。这个可能需要在做的时候处理。 验证保密问题，公司居然都没有人提到这点。不过也对我们是通过手机号进行验证的。但是如果以后我们不在使用手机号，可能我们需要验证问题。还需要判断用户的活动记录...
阅读全文

通用系统设计之优惠卷

前言 本应该继续连载手撸框架系列文章的。但最近有一个需求 -> 优惠卷，之前很多朋友让我出一篇优惠卷相关的文章。这不，本章应了大伙的愿。开始我自己的表演 🔥🔥 额,这里还要插一句，有很多新人感觉在使用框架的过程中根本用不到PHP的很多概念，例如abstract,final 部分人感觉protected,private 都没有太大用处。更别提interface在框架中的使用了，感觉好无用处的举爪～ 策略模式 优惠卷的存在到消亡至少要经历三个步骤（创建->使用->失效），以下为优惠卷完整生命周期图， 优惠卷有几百种几千种的优惠（骗人）方式（姿势），结合PHP代码来解决优惠卷应如何创建更合适，首先先创建一个类作为优惠卷的模版 class UserCouponTem { } 这个模版则是一个树根，未来所有优惠卷都要通过这个根去扩展，接下来创建一系列的优惠卷参数，例如与设计数据表一样,如下所示，通过成员变量的方式，束缚了优惠卷的具体字段。 /** * @var $couponName * @content 优惠券名称 */ public $couponName; /** * @var $alidityv * @content 有效期 */ public $alidityv; /** * @var $userId * @content 绑定的用户编码 */ public $userId; /** * @var $price * @content 抵扣金额 */ public $price; /** * @var $type * @content 类型 0 通用红包 1 查看扩展字段 */ public $type; /** * @var $extend * @content 扩展字段 */ public $extend; /** * @var $numbers * @content 卷号 */ public $number; /** * @var $content * @content 卷内容 */ public $content; 优惠卷的模版创建完成后，接下来需要创建两个方法，第一个为服务...
阅读全文