开源软件

最初感激Gitee对Choerodon猪齿鱼的必定，在此要特别感谢Choerodon猪齿鱼社区的每一位成员在Choerodon猪齿鱼成长中的奉献，你们的参加和见证是Choerodon猪齿鱼成长最好的营养，让咱们独特为企业数字化服务打造一个凋谢的生态平台。

Choerodon猪齿鱼开源全价值链多云麻利合作平台，是基于开源技术Kubernetes，Istio，knative，Gitlab，Spring Cloud来实现本地和云端环境的集成，实现企业多云/混合云应用环境的一致性。目前对于通过 Choerodon 开发部署的利用零碎有多种部署形式——kubernetes集群部署，主机 JAR 包和 Docker 部署，所以请根具部署形式的不同请灵便抉择零碎架构。 装置形式Choerodon提供两种装置形式，即一键部署Choerodon和分步部署Choerodon。上面将介绍一键部署最小化装置Choerodon。 环境筹备硬件最低要求服务器总内存：32G及以上服务总CPU数：8外围及以上单节点硬盘：100Gb及以上（如应用NFS存储，那么NFS服务节点倡议存储不小于512G）软件要求零碎版本：CentOS7.4及以上Kubernetes：1.10及以上Helm：v3.2.4及以上网络要求各个服务器之间内网互通内网带宽倡议1Gbps以上各个服务器可能拜访外网上面将以一台8外围32G内存的服务器为例，演示如何装置猪齿鱼。 装置步骤装置 Choerodon 首先实现 kubernetes 集群的部署和 helm 装置；而后部署 NFS 服务器端，如果你抉择其余类型的存储，能够疏忽NFS相干的搭建信息；接着应用猪齿鱼命令行工具一键式装置 Choerodon；最初部署 Gitlab Runner，其用于代码提交后主动进行代码测试、构建服务的镜像及生成helm chart并将后果发回给Choerodon。 Kubernetes 集群装置筹备装置脚本# 装置 git 命令行sudo yum install git -y# 克隆本我的项目代码git clone https://gitee.com/open-hand/kubeadm-ha.git# 进入我的项目目录cd kubeadm-ha# 装置 ansible 环境sudo ./ansible/install.sh配置 ansible inventory 文件我的项目 example 文件夹下提供了 6 个 ansible inventory 示例文件，请按需要进行抉择并批改。 拷贝我的项目下的 example/hosts.allinone.hostname.ini 文件至我的项目根目录下，命名为 inventory.ini，批改kubernetes部署版本为 1.16.15、各服务器的 IP 地址、用户名、明码，并保护好各服务器与角色的关系。 ; 将所有节点的信息在这里填写;    第一个字段                  为 kubernetes 节点 nodeName，留神必须由小写字母、数字，“-”或“.”组成，并且必须以小写字母或数字结尾和结尾;    第二个字段 ansible_host     为节点内网IP;    第三个字段 ansible_port     为节点 sshd 监听端口;    第四个字段 ansible_user     为节点近程登录用户名;    第五个字段 ansible_ssh_pass 为节点近程登录用户明码[all]node1 ansible_host=192.168.56.11 ansible_port=22 ansible_user="vagrant" ansible_ssh_pass="vagrant"; 单节点lb节点组留空。[lb]; 留神etcd集群必须是1,3,5,7...奇数个节点[etcd]node1[kube-master]node1[kube-worker]node1; 预留组，后续增加master节点应用[new-master]; 预留组，后续增加worker节点应用[new-worker]; 预留组，后续增加etcd节点应用[new-etcd]; 预留组，后续删除worker角色应用[del-worker]; 预留组，后续删除master角色应用[del-master]; 预留组，后续删除etcd角色应用[del-etcd]; 预留组，后续删除节点应用[del-node];-------------------------------------- 以下为根底信息配置 ------------------------------------;[all:vars]; 是否跳过节点物理资源校验，Master节点要求2c2g以上，Worker节点要求2c4g以上skip_verify_node=false; kubernetes版本kube_version="1.20.2"; 容器运行时类型，可选项：containerd，docker；默认 containerdcontainer_manager="containerd"; 负载均衡器;   有 nginx、openresty、haproxy、envoy  和 slb 可选，默认应用 nginx;   为什么单节点 apiserver 也应用了负载平衡请参加此探讨： https://github.com/TimeBye/kubeadm-ha/issues/8lb_mode="nginx"; 应用负载平衡后集群 apiserver portlb_kube_apiserver_port="8443"; 网段抉择：pod 和 service 的网段不能与服务器网段重叠，; 若有重叠请配置 `kube_pod_subnet` 和 `kube_service_subnet` 变量设置 pod 和 service 的网段，示例参考：;    如果服务器网段为：10.0.0.1/8;       pod 网段可设置为：192.168.0.0/18;       service 网段可设置为 192.168.64.0/18;    如果服务器网段为：172.16.0.1/12;       pod 网段可设置为：10.244.0.0/18;       service 网段可设置为 10.244.64.0/18;    如果服务器网段为：192.168.0.1/16;       pod 网段可设置为：10.244.0.0/18;       service 网段可设置为 10.244.64.0/18; 集群pod ip段，默认掩码位 18 即 16384 个ipkube_pod_subnet="10.244.0.0/18"; 集群service ip段kube_service_subnet="10.244.64.0/18"; 调配给节点的 pod 子网掩码位，默认为 24 即 256 个ip，故应用这些默认值能够纳管 16384/256=64 个节点。kube_network_node_prefix="24"; node节点最大 pod 数。数量与调配给节点的 pod 子网无关，ip 数应大于 pod 数。; https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidrkube_max_pods="110"; 集群网络插件，目前反对flannel,caliconetwork_plugin="calico"; 若服务器磁盘分为系统盘与数据盘，请批改以下门路至数据盘自定义的目录。; Kubelet 根目录kubelet_root_dir="/var/lib/kubelet"; docker容器存储目录docker_storage_dir="/var/lib/docker"; containerd容器存储目录containerd_storage_dir="/var/lib/containerd"; Etcd 数据根目录etcd_data_dir="/var/lib/etcd"%集群部署部署集群： ...

摘要随着我行自动化测试施行范畴的不断扩大，参加界面自动化测试的利用零碎越来越多。我行的利用零碎现阶段多采纳商用工具QTP（UFT）作为执行工具来进行界面自动化测试，洽购的QTP license是无限的，使得资源的竞争越来越强烈。将来，应用开源/收费的界面自动化测试代替QTP，是必然倒退的趋势。 本文基于后期调研后果，比照剖析了几款业界支流的开源界面自动化测试工具，供自动化测试相干人员学习参考。 关键字：开源、自动化测试、Selenium、UIAutomation 一、调研背景与意义自动化测试由手工测试倒退而来，在以后商业银行“继续迭代、疾速交付”的大背景下，自动化测试是必然趋势。对于投产前的全量回归测试和大量数据的业务逻辑笼罩测试，自动化测试将大大的缩小人力投入，晋升测试效率，扩充测试覆盖面，升高投产危险。 后期，我行界面自动化测试工具次要依赖QuickTest Professional（简称QTP，现已降级更名为UFT）。该软件具备价格昂贵、客户端架构宏大、license无限、对局部C/S类利用（比方：BoEing客户端、银企通客户端、海内分行OIBS客户端等）反对不良等起因，其被开源或收费的自动化测试工具取代是必然趋势。 二、工具介绍后期，零碎反对部组织调研了十余款界面自动化测试工具，上面介绍几种业界支流的开源/收费界面自动化测试工具。 2.1 SeleniumSelenium是Throught Works公司开发的开源Web性能测试工具集，是以后web端系统最受欢迎的开源自动化测试工具之一。Selenium蕴含了测试的录制（Selenium IDE），测试的并行处理（Selenium Grid），编写与运行（Selenium Remote Control）。 Selenium Grid次要架构图如图1所示，Selenium Grid次要蕴含两个外围组件：Selenium Hub与Remote Control（简称RC，或Selenium RC）。Selenium hub负责散发测试用例给Selenium RC；Selenium RC负责调用浏览器驱动运行自动化测试脚本。 图1 Selenium Grid架构图 Selenium中定义了如下弱小的形容元素的定位办法： 通过id、name定位，如：selenium.tye(“id=abc”,“百度”)；selenium.type(“name=search”,“百度”)。通过link=链接文字定位，如selenium.click(“link=最近更改”)。依据xpath定位，如selenium tpye(“xpath=//input[@name=‘user.email’,“xxx@qq.com”)。Dom抉择及Css选择器定位（不罕用）。2.2 UIAutomationUIAutomation是微软开发的界面自动化测试工具，是.NET Framework的组件之一，可进行C/S类利用的界面自动化测试。此自动化库一开始就是为可拜访性和UI测试自动化工作而专门设计的，应用UI自动化库来测试运行反对.NET Framework的操作系统，例如Windows XP、Windows Vista、Windows 7、Windows Server 2003和Windows Server 2008等操作系统主机上的Win32应用程序、.NET Windows窗体应用程序和WPF应用程序。 在UIAutomation中，所有的窗体、控件都体现为一个AutomationElement，AutomationElement中蕴含此控件或窗体的属性，在实现自动化的过程中，通过其相干属性进行对控件自动化操作。所有显示在桌面上的UI，其实际上是一个UI Tree，根节点是Desktop。 在UIAutomation中，根节点示意为AutomationElement RootElement。通过根节点，能够通过窗体或控件的Process Id、Process Names或者Windows Name找到相应的子AutomationElement，例如Dialog、Button、TextBox、CheckBox等规范控件，通过控件所对应的Pattern进行相干的操作。 UIAutomation的体系结构如图2所示： 图2 UIAutomation的体系结构 在服务端由UIAutomationProvider.dll和UIAutomationTypes.dll提供；在客户端由UIAutomationClient.dll和UIAutomationTypes.dll提供；UIAutomationCore.dll为UI自动化的外围局部，负责Server端和Client端的交互；UIAutomationClientSideProvides.dll为客户端程序提供自动化反对。2.3 WatirWatir是基于Ruby库的开源Web自动化测试工具，反对Firefox、Opera、IE等浏览器。Watir脚本以.rb为文件扩展名，脚本头应为“require ‘watir’”，确保能够拜访Watir工具。Watir脚本的运行模式是Watir-WebDriver，Watir-WebDriver是基于Ruby开发web驱动框架，反对所有的HTML元素。目前网上对于Watir的介绍材料较少。 在设计Watir自动化测试脚本时须要相熟罕用的Ruby脚本语法。Watir罕用语法列举如下： 创立一个IE的测试实例：ie=Watir::IE.new或者应用start办法创立一个浏览器实例并转到一个页面，ie=Watir::IE.start(“http://abc.com”;)；页面导航：ie.goto(“http://abc.com”;)；操纵超链接、复选框、下拉框等Web页面对象，例：应用name属性设置复选框，ie.checkbox(:name,”check”).set。2.4 SahiSahi是一款由印度公司Tyto Software开发的基于业务的开源Web自动化测试工具。Sahi运行为一个代理服务器，并通过注入JavaScript来拜访Web页面中的元素。Sahi反对HTTPS并且独立于Web站点，简略玲珑却功能强大。它绝对于Selenium等自动化测试工具，在动静ID元素查找和隐式页面期待解决等方面具备肯定的劣势。 Sahi简略易用，可能很好地反对Ajax和Web2.0技术，同时实用于麻利和瀑布两种我的项目模式。Sahi自带录制性能，反对简直所有的浏览器，且对JS反对较好，具备页面期待判断机制、内置Java异样报告、反对Ajax等劣势。尤其值得一提的是，Sahi内置的智能页面期待机制，可能主动判断Ajax申请是否曾经处理完毕，而后持续下一步操作。并且这一点对于用户是“隐式”的，不须要减少额定的代码。 Sahi的工作原理大抵分为三步：录制、精炼脚本和回放，具体步骤如下： 录制：首先将Sahi其设置为浏览器的代理服务器，这样Sahi的脚本就可能通过request申请，注入到JavaScript里以拜访Web页面中的元素。精炼脚本：录制的脚本都是指定元素并惟一操作的，这时就须要对代码进行重构，抽取出外围的功能块，对其中的元素进行参数化解决，以实现重用。脚本中的数据能够从内部的数据库或文件中读取而来。同时，也可调用Sahi的API或内部Java等API实现一些特定的性能。回放：主动执行Sahi精炼好的脚本，并生成测试报告。2.5 Katalon StudioKatalon Studio是一款功能强大的测试自动化解决方案，实用于Web应用程序，反对Mobile、Web、API等类型的自动化测试。它基于Selenium和Appium框架构建，Katalon Studio利用这些解决方案实现集成软件自动化。 Katalon Studio能够集成到CI/CD流程中，并且能够与QA流程中的风行工具配合应用，包含qTest，JIRA，Jenkins和Git。它还提供一个称之为Katalon Analytics的性能，这个性能能够通过仪表板为用户提供测试执行报告的全面视图，包含图表、图形和指标等。Katalon Studio能够治理页面元素、测试数据、测试案例、生成自动化测试报告等，笼罩整个自动化测试流程及所需资产。Katalon Studio容许用户自定义Method，Test Listeners、KeyWord，也能够导入内部的jar包实现更为简单的性能，该工具的扩展性很强。 ...

新增积分兑换机制课程减少原价属性gitee提交webhooks自动化部署脚本更新course和chapter数据迁徙文件中脱漏了recourse_count字段app/Caches/TopicCourseList不存在Model文件属性定义默认值暗藏非付费课程的咨询服务教学中心老师直播推流按钮无反馈用户核心局部款式调整播放器清晰度标签和理论的清晰度不对应CNZZ统计代码会显示出站长统计图标主动装置后拜访站点500谬误自动更新脚本可更新css和js版本号我的项目介绍酷瓜云课堂，依靠腾讯云根底服务架构，采纳C扩大框架Phalcon开发，GPL-2.0开源协定，致力开源网课零碎，开源网校零碎，开源在线教育零碎。 零碎性能实现了点播、直播、专栏、会员、微聊等 托管仓库gitee仓库github仓库意见反馈在线反馈（举荐）官方论坛（举荐）开源助力毫无保留的真开源不容易，如果对你有帮忙，请给咱们 STAR ！！！

理解 Ant DesignAnt-Design是蚂蚁金服基于React开源的一款企业级UI 设计语言和 React 组件库，深受人们青睐。 最早音讯还在以后过年的工夫点，Ant Design的Github库蒙受删库袭击。 最早呈现的信息是在2月15日凌晨一位叫Jeggy的用户在stackoverflow上发文示意无法访问Ant Design源码库。 他示意Ant Design源码库关上显示404，官方网站https://ant.design/ 打不开，然而npm的包仍旧能够下载应用。 Ant Design官网 示意正在考察起因只修复了ant.design网站，对于Github源码库的修复工作正在找Github官网寻求帮忙。这个事件不会影响Ant Design框架的用户，Github上Ant Design源码仓库的我的项目所有者没有发生变化，正在和Github官网一起复原源码库。初步考察认定是Github账号被黑客攻击了，具体起因还须要期待官网具体确认。 以后Ant Design新创建了一个长期的源码仓库，介绍只有简短的一句话： antd repo disappear, we are contacting to GitHub. stackoverflow地址：https://stackoverflow.com/questions/66197823/what-has-happened-to-ant-design-deleted-from-github

近日，IBM 制订了量子计算的软件路线图，其中包含往年公布的 Qiskit 运行时，到 2023 年更新的软件接口、电路库和控制系统。 IBM 预计，到 2025 年，将会呈现无摩擦量子计算，从而实现超过经典计算的广泛应用。很多事件都取决于一个叫做 Qiskit 的开源软件，该软件将作为进一步量子软件开发的根底。 2020 年 9 月，IBM 概述了其量子计算硬件路线图，明天颁布的是其量子计算的软件路线图。 BM 量子生态系统开发副总裁 Bob Sutor 示意，概述软件路线图对于心愿投资量子计算的开发者和企业至关重要。“路线图使人们对预期的冀望和工夫更有信念。咱们的确心愿这能带来更多的确定性。” Sutor 说他们的指标是建设一个软件生态系统，达到量子计算胜过传统办法的境地。路线图的大部分内容都围绕着打消量子零碎中的乐音和误差开展。他说，“这是一个不同的编程模型，咱们正在混合软件开发构造”。 因为量子计算机是物理零碎，所以软件的开发是为了纠正错误和减少容错能力。最终，开发人员将取得量子计算编程常识。Sutor 指出，IBM 的量子课程引起了很多人的趣味。Sutor 说：“如果你懂 Python，你就能够学习量子计算，你只需确定进入堆栈的地位即可。就算只是一名大二的学生，只有想好了，就能够利用 Qiskit 来做这所有。” 要害亮点：IBM 正在致力于与 OpenQASM3 汇编语言的接口，这将容许量子内核开发人员在 2020 年之前运行动静电路。 IBM 打算在 2023 年之前推出电路库和高级控制系统，以治理大型量子构造。这一行动将容许内核开发者扩大1000个或更多 qubit 的硬件。在内核层开发之后，量子算法开发人员将参加其中。这些开发人员将至关重要，因为他们将为量子电路创立新的应用程序。 到 2023 年，IBM 将应用通用开发框架提供可从基于云的 API 调用的预构建运行时。在这一点上，量子零碎将足够形象，以吸引更多的开发人员。IBM 打算在 Red Hat OpenShift 和凋谢规范的根底上开发量子软件工具。通过 OpenShift Qiskit 操作系统，开发者能够装置 Jupyter 笔记本和 Qiskit SDK。 在 2025 年，因为云计算和 API 的存在，量子计算在硬件上的细微差别对用户和开发者来说都不再重要。IBM 预计到 2030 年，公司和用户每天将运行数十亿甚至数万亿的量子电路。 ...

随同着开源产业的蓬勃发展，开源技术成为助力产业数智化改革的要害力量，开源企业更是受到资本的青眼。据不齐全统计，仅在过来一年，国内先后有超过10家开源企业取得新一轮融资，融资纪录为近年来开源赛道最高。与此同时，大公司开源步调减速、国内第一家开源基金会正式成立等音讯，也成为了去年外乡开源畛域的重磅新闻。 随着越来越多的企业、人才、资金等大量涌入，在外乡开源这一赛道之上，将来将涌现出更多优良的开源参与者。然而，在参加开源的过程中，更多有对于企业开源治理、社区经营等方面的难题，却仍然困扰着每一位投身开源的人。 去年4月16日，Apache软件基金会发表Apache ShardingSphere毕业并成为顶级我的项目，成为基金会内首个分布式数据库中间件我的项目，这意味着Apache ShardingSphere在开源实际上获得的成绩，取得了国内顶级开源组织的认可。而在这亮眼问题的背地，ShardingSphere我的项目经验哪些阶段？一个沉闷的、衰弱倒退的开源社区须要具备哪些因素？企业在开源生态建设中又该面临哪些挑战？ 近日，由InfoQ特地策动并推出「开源翻新30人」系列采访报道中，InfoQ记者与京东科技架构师，Apache ShardingSphere我的项目VP&创始人张亮进行了一次深刻交换。局部答案可在对话中得以揭晓。 ▲京东科技架构师，Apache ShardingSphere我的项目VP&创始人张亮▲ ShardingSphere的三次变质在开始企业开源治理及开源社区建设的话题之前，首先得从张亮及Apache ShardingSphere的倒退说起。 截至目前，ShardingSphere我的项目已有150+公司采纳，并涵盖金融、电商、数字化与云服务、互联网教育、出行、物流、医疗衰弱等各行各业，在京东外部也被宽泛采纳。事实上，从写下第一行代码到获得明天这样的问题，ShardingSphere次要经验了三个阶段的倒退。 在开源初期，过后还被命名为Sharding-JDBC的ShardingSphere次要由张亮集体主导，是一款基于Java JDBC接口实现的数据库分库分表治理框架。 据张亮介绍，过后决定写下第一行代码的起因，次要是因为行业内的数据库中间件长期没有足够成熟且能让大家宽泛采纳的产品。 张亮示意： “ 不同阶段的开源我的项目都让人感觉毛病什么，比如说对SQL的反对度不高，工具也不成熟，而且开源一段时间就没人保护了，都是些半成品 。 ” 抱着扭转这一现状的初衷，过后对社区都没什么概念的他便写下了Sharding-JDBC的第一行代码。 而在第一个版本的产品成型并公布后，因为Sharding-JDBC很好地屏蔽掉了数据长久化过程中分库分表等方面的实现细节，让开发者可能更轻松地实现数据库的程度扩大，产品开源后便取得了开发者的统一好评。 随后，随同着Sharding-JDBC在开源社区失去认可，过后打算自研分布式数据库的京东科技团队也找到了张亮，无意邀请他退出。再三思考后，张亮最终退出京东科技，全职做起了Sharding-JDBC，也从此开启了Sharding-JDBC第二阶段的倒退旅途。 据张亮介绍，因为设计之初Sharding-JDBC次要是 基于JDBC标准接口实现的， 整体上更像是一款Java数据分片框架，因而也存在只能用于Java上的局限性。但事实上，业务利用开发语言不止Java一种，实现从一个Java框架到更为通用的跨语言数据库中间件产品的转变，Sharding-JDBC还有许多须要晋升的中央。 首先是品牌的降级，将Sharding-JDBC改名成为了ShardingSphere，在保留原来开源框架累计下来的人气与品牌关注度的同时，进一步强调本人曾经跳出了最后Java框架的固有产品形象。 与此同时，张亮还开始着手经营与组建社区，思考将ShardingSphere推入Apache基金会，将其倒退成为更加大众化的、可能成为开源数据库中间件畛域规范的产品。 2018年11月，随同着ShardingSphere正式进入Apache孵化，随后又于17个月之后正式毕业成为Apache顶级我的项目，在先后实现了社区组建，同时遵循Apache的规定将ShardingSphere所有权从公司与集体转向社区所有之后，ShardingSphere根本实现了第二阶段的转变。 在进入第三阶段之后，可插拔架构的提出，也开始成为了ShardingSphere倒退须要思考的问题。 据张亮介绍，可插拔思路的成型，次要是因为在应用ShardingSphere的过程中，京东外部除了对数据分片和读写拆散等需要外，也逐步衍生出了包含数据加密、影子库压测等这一类的需要。这些性能如果别离让各个系统部门本人去实现，就会呈现反复造轮子的景象，但如果可能将这些性能中比拟通用的能力抽离进去，集成到ShardingSphere之上，这就会极大地缩小公司整体的工作量。 而在将这些性能集成到ShardingSphere的过程中，如何实现性能之间的相互隔离，不影响主架构运行，成为了ShardingSphere“可插拔架构”提出的要害。 据张亮介绍，在技术架构上，ShardingSphere的可插拔架构划分为面向数据库内核、企业应用和开源生态的三个层级。 L1内核层：面向数据库内核，包含查问优化、分布式事务、外围执行链路、调度引擎和分布式治理等。L1内核层是ShardingSphere通过对行业的思考所提供的解决方案。通过可切换的双引擎，在分布式数据库尚未成熟的改革阶段提供中间件增量服务；并在终将到来的分布式数据库成熟之时提供面向分布式的查问优化、事务和存储引擎。心愿L1内核层的可插拔设计，能帮忙传统数据库向分布式和云原生阶段提供安稳的演进门路。当然，目前内核层还属于策划阶段。 L2性能层：面向企业应用，包含数据分片、读写拆散、数据库高可用、强统一多正本、弹性迁徙、数据加密、影子库以及其余扩大。它是开发者能够自行拓展的重点局部。L2性能层对于企业级利用意义重大，目前L2性能层曾经较为欠缺。 L3生态层：面向开源生态，包含SQL方言、数据库协定以及数据网关。除了对繁多数据库兼容度的晋升，对异构数据源的买通数据网关也在摸索中。L3生态层将是ShardingSphere对接和融入开源生态的规范。 从最后基于Java语言开发并开源的数据库分库分表框架开始，ShardingSphere一路随着市场的需要不断更新，先后经验了性能降级、治理模式切换，进入开源基金会等过程，逐步演变成为了一个分布式的数据库生态体系。 社区大于代码的含意是“独行致快，众行致远”一路转型降级的过程中，张亮对于开源的了解也在一直地晋升。 从写下第一行代码到第一个开源版本公布，张亮用了三个月就实现了所有工作，在之后两年的经营过程中，张亮集体奉献的代码量也一度达到80%以上。然而开源之后，如何让整个我的项目长期稳固地运行上来，却成为了让张亮思考最多的问题。 一个我的项目的代码再好，但如果他是属于一个人的，那其实它的危险是十分大的。因为随着维护者的情绪变动，可能这个我的项目可能会突然就失去保护，或者开始保护很慢。从企业应用的角度来看，这样的我的项目是不被看好的。 在张亮看来，一个开源我的项目想要真正取信于人，肯定是它要有一个稳固的基座，这个基座不能是第二天就会隐没的货色。 而在亲历了ShardingSphere从进入Apache孵化到毕业的全流程之后，他为本人的这一理念找到了新的解释。 在Apache基金会内，“社区大于代码”的理念渗透到整个基金会经营决策的每一个环节，一句话便高度概括了Apache的经营倒退之道。但在张亮看来，“社区大于代码”其实又能够解释为“独行致快，众行致远”。 张亮示意： “ 一个人去写代码可能会很快，然而只有更多的人一起参加进来，即便当我的项目的创始人累了不想走了的时候，背地也有他人在推着他向前走，并且常常会有一些乏味的新办法呈现，刺激大家一起往前 。 ” 对于如何打造一个继续沉闷、衰弱倒退的社区？张亮总结了以下五点教训： 第一，须要多去听多看。通过GitHub和邮件列表这些渠道，再小的声音都可能反馈到社区外部，我的项目经营人员通过这些渠道聆听参与者的声音，可能提炼出更加通用、普适的需要，进一步迭代出更加欠缺的性能，让开源我的项目的社区变得更加有生机，倒退更为持重。 第二，要放弃英文化。社区是多元的，下面汇集了来自不同国家、地区乃至于文化背景的人，咱们不心愿社区是一个割裂的状态，对立用英文沟通，是对社区多元化的一个最根本的保障，它不会让一些想参加它的外国人，因为语言壁垒最终无奈参加。 第三，每一次问题提交都要做到可检索。所有用户提的问题都须要尽量留痕，如果某一用户提了一个他本人没想分明的问题，或者抛了一个空指针之后又关掉了页面，最好的形式就是揭示他将本人的问题欠缺或改到容易被检索的状态，因为这些问题可能之后会有其余的人看到，能给别人带来启发，这是存在价值的。与此同时，也须要定期去做一些问题的梳理与标签设置，让社区可能更好地理解我的项目当下的停顿。 第四，须要有一个弱小的测试零碎。因为参加开源的人比拟多，沟通的工作量也十分大，如果提交者上传的代码没有通过必要的后期测试就通过了，这导致的后果是，我的项目正确性的责任全副由前面代码审核的人负责，代码实现的分工将变得不那么正当。 第五，要防止反复造轮子。须要站到更高的维度去看问题，开源的生态还包含社区的交换共享，他人可能会用你的我的项目，你也须要适当地去采纳他人的我的项目，防止做一些反复造轮子的事件。 “对于开源而言，最重要的不是代码的实现，而是代码背地的服务，及其对应的整个社区生态所蕴含的价值。”张亮示意。而在这一教训的领导和超200名社区参与者的共同努力下，ApacheShardingSphere在2020年Linux基金会旗下的OpenSSF的开源我的项目要害评分中，获得了Java语言类第72名，国人主导的开源我的项目第1名的亮眼问题。 企业须要凋谢更多的开源岗位在刚过去的2020年，随同着越来越多基于开源模式的企业在商业上取得市场认可，国内呈现了一批被投资者选中的开源我的项目，开源守业的春天，未然降临。 然而对于外乡开源而言，在开源越来越热的当下，外乡开发人员底层研发能力单薄，工程能力大多停留于使用层的局限性，也正在制约着外乡开源生态的倒退成型，这些问题并不是短期内可能解决掉的。 在加入了无数场国内顶级的开源峰会之后，张亮最大的一个感触是，国外参会的开发者在40岁到60岁之间的人员仍然很多，然而国内的参会者却广泛在30多岁之间。 张亮示意： “ 技术自身还是一个熟练工种，你在这个畛域积淀得越深了，累积的能力也便越强 。 ” 在其看来，一个人在某一畛域的思维变得十分沉闷，而且教训也很丰盛的时候，往往是这个人在这个畛域耕耘了超过十年以上的时候，但国内的工程师在整个时间段的时候，可能曾经转移到其余岗位上了。 将来外乡开源生态的欠缺，仍有很长的路须要走。而针对这一现状，张亮给出的倡议是——大型企业在参加开源治理的同时，须要凋谢更多全职的开源岗位。 张亮示意： “ 大型科技公司其实是心愿有本人开源方面输入的需要的，这种输入的目标，其实是心愿寻求对于行业标准的影响，进一步霸占更多的话语权，博得行业关注和口碑 。 ” 在其看来，尽管大型企业参加开源实质上并不是100%奔着开源去的，但如果能让这些企业内参加开源的人投入50%的工夫去做开源，就曾经很足够了。 张亮示意： “ ...

对于 Apache PulsarApache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。GitHub 地址：http://github.com/apache/pulsar/ 本内容由 StreamNative 团队整顿，编辑：鸡排@StreamNative，如需转载请后盾留言沟通。 Apache Pulsar 社区迎来 95 后——最年老 Committer继 2021 年初，Apache Pulsar 社区喜迎来自腾讯云的林琳退出 Apache Pulsar Committer 团队后，在 1 月中旬，来自 StreamNative 的张勇（GitHub 地址：@zymap）也入选 Apache Pulsar Committer。 值得一提的是，出生于 1997 年的张勇是 Apache Pulsar 社区的“老人”了。他于 2019 年 2 月 Pulsar 中文社区晚期即退出了 Pulsar 社区。在两年的工夫内，张勇为 Apache Pulsar 做出了许多奉献：maxMessageSize 反对，使 Pulsar 反对大于 5MB 的音讯、反对 admin 配置多地址性能、增加 transaction、反对 package management service 等等。作为社区最年老 Committer，张勇的退出为 Apache Pulsar 我的项目注入了新生代独有的生机。 恭喜张勇成为 Apache Pulsar 社区 Committer！同时，咱们也对张勇做了书面采访，聊聊他与 Apache Pulsar 的故事。 ...

值班编辑：袁钰涵 1、AWS 开源：与社区一起逐渐实现真正开源的 Elasticsearch近日，Elastic 在官网发文称将对 Elasticsearch 和 Kibana 在许可证方面进行了重大的更改，由开源 Apache 2.0 许可证改为采纳 Elastic License 和 SSPL（服务器端公共许可证）。 对于 Elastic 的这一决策，AWS 在 AWS 开源博客官网博客发表文章《Stepping up for a truly open source Elasticsearch》 — Elastic 正在毁坏凋谢源代码自身的定义，而 AWS 将加紧创立和保护由开源 Elasticsearch 和 Kibana 取得 Apache 许可 2.0 版（ALv2）许可的分支。 2、浪潮 UBML 低代码建模体系正式开源2021年1月20日，UBML 我的项目代码正式对外开放。目前凋谢的代码有建模规范（UBML-Standard）及 UBML-Models，包含面向后端开发的外围模型BE（Business-Entity）、VO（View-Model）和服务模型中的 EAPI（External-API）。我的项目团队在凋谢原子开源基金会的孵化过程中，将持续凋谢出更多组件以丰盛生态的倒退，欢送更多的敌人独特参加。 UBML（Unified-Business-Modeling-Language）是一种基于畛域特定语言的、用于疾速构件应用软件的低代码开发建模语言，是浪潮 iGIX 企业数字化能力平台的外围低代码建模体系。UBML 是凋谢原子开源基金会旗下的孵化我的项目。 UBML 作为低代码开发平台的开发语言，是低代码开发平台的外围根底，蕴含开发语言无关性的建模规范（UBML-Standard），内置了基于 UBML 规范的全栈业务模型（UBML-Models），并提供了可与模型进行全生命周期交互的开发服务与套件（UBML-SDK）及撑持模型运行的运行时框架（UBML-Runtime）。将来，UBML 将引入更多低代码开发工具（UBML-Designer）等，造成残缺的低代码开发平台。 UBML 解决了什么问题？ 随着数字化转型成为支流，软件作为数字化转型的业务载体，其需求量产生了井喷式增长。Gartner 预计，2021 年市场对于利用开发的需要将五倍于 IT 公司的产能。为填补这一产量缺口，低代码/零代码技术是目前惟一可行的解决方案，必然会有越来越多企业引入这一技术。 低代码开发是一种软件疾速开发方式，能够让开发人员通过大量代码甚至零代码实现业务利用的开发。UBML 作为低代码开发平台的外围根底，致力于解决传统代码开发模式下老本高、门槛高，开发速度、灵活性、敏捷性差的问题。能够进步生产力，实现降本增效，为企业数字化转型提供动能。 3、腾讯多环境配置及抓包调试平台 Nohost 正式开源腾讯开源公众号公布音讯称由腾讯 IMWeb 前端团队打造的一个多环境配置及抓包调试平台正式开源。 ...

在UBML我的项目团队与凋谢原子开源基金会的共同努力下，UBML代码仓库正式对外开放2021年1月20日，UBML 我的项目代码正式对外开放。目前凋谢的代码有建模规范（UBML-Standard）及 UBML-Models，包含面向后端开发的外围模型BE（Business-Entity）、VO（View-Model）和服务模型中的 EAPI（External-API）。我的项目团队在凋谢原子开源基金会的孵化过程中，将持续凋谢出更多组件以丰盛生态的倒退，欢送更多的社区敌人独特参加。 UBML 我的项目外围贡献者-郝志北 UBML 我的项目外围贡献者-李斌 UBML 我的项目外围贡献者-宫保金 什么是 UBML（Unified-Business-Modeling-Language）？UBML（Unified-Business-Modeling-Language）是一种基于畛域特定语言的、用于疾速构件应用软件的低代码开发建模语言，是浪潮 iGIX 企业数字化能力平台的外围低代码建模体系。UBML 是凋谢原子开源基金会旗下的孵化我的项目。 UBML 作为低代码开发平台的开发语言，是低代码开发平台的外围根底，蕴含开发语言无关性的建模规范（UBML-Standard），内置了基于 UBML 规范的全栈业务模型（UBML-Models），并提供了可与模型进行全生命周期交互的开发服务与套件（UBML-SDK）及撑持模型运行的运行时框架（UBML-Runtime）。将来，UBML 将引入更多低代码开发工具（UBML-Designer）等，造成残缺的低代码开发平台。 UBML 解决了什么问题？随着数字化转型成为支流，软件作为数字化转型的业务载体，其需求量产生了井喷式增长。Gartner 预计，2021 年市场对于利用开发的需要将五倍于 IT 公司的产能。为填补这一产量缺口，低代码/零代码技术是目前惟一可行的解决方案，必然会有越来越多企业引入这一技术。 低代码开发是一种软件疾速开发方式，能够让开发人员通过大量代码甚至零代码实现业务利用的开发。UBML 作为低代码开发平台的外围根底，致力于解决传统代码开发模式下老本高、门槛高，开发速度、灵活性、敏捷性差的问题。能够进步生产力，实现降本增效，为企业数字化转型提供动能。 UBML 是如何解决上述问题的？提供基于模型驱动的低代码开发方式，显著晋升软件开发效率。通过可视化建模开发，升高软件开发门槛，突破技术与业务的隔膜，简略需要可由业务人员间接响应，疾速上线，促成软件开发平民化。通过代码主动生成和基于模型的执行引擎，最大水平缩小人工编码的不规范性与出错率，保障软件开发标准化。通过开放式全栈模型体系与可交融的利用生态，丰盛工业利用的软件生态，助力企业实现数字化翻新转型。 UBML 的次要技术个性UBML 的规范与内置模型解耦，规范具备开发语言无关性，可与各种畛域规范（例如 OpenAPI、BPMN）进行集成与适配，模型的品种可基于 UBML 外围机制，依照行业类型或利用类型进行扩大定制，具备良好的开放性与扩展性。目前，业内的低代码平台次要分为两种模式：一种是基于引擎的解析型模式；一种是基于源代码生成的生成型模式。UBML 提供了同时反对上述两种模式的混合（Hybrid）模式。无论是解析型模式，还是生成型模式，两者均基于经典的模型驱动架构（MDA），以模型为外围，因而模型的丰盛度与深度代表着低代码平台的外围能力。UBML 提供了几十种涵盖了从前端到后端的全栈业务模型体系，将为低代码平台的建模与开发能力提供全面撑持。UBML 基于“模型即源码”的理念，将模型视作源代码进行工程化治理，能够与支流研发过程管理工具进行集成，反对 DevOps。此外，UBML 还提供对立的模型全生命周期治理能力。 UBML 的愿景UBML 定位于工业互联网平台中的 APaaS 层，致力于打造低代码开发建模的事实标准、建成 IT 侧面向工业利用开发的规范技术组件、构筑丰盛的工业互联网利用生态。 UBML 开源是浪潮 iGIX 开源策略的第一步，目前 UBML 提供的运行时组件（UBML-Runtime）次要面向工业利用中的经营治理类软件，后续，UBML 将在开源社区中发展多方单干共建，踊跃扩大多种工业利用类型，并拟向 OT 侧延长，倒退 IoT、智能化开发、数据驱动型利用等多个方向，借助社区力量，摸索工业互联网畛域的残缺解决方案。 UBML 的开源路标2021年1月20日，UBML 开源了建模规范（UBML-Standard）以及 UBML-Models中，面向后端开发的外围模型 BE（Business-Entity）、VO（View-Model）和服务模型中的 EAPI（External-API）。更多模型，将继续凋谢。2021年3月，UBML 将凋谢残缺的 SDK、Runtime 及 CLI 工具。截至2021年12月，打算实现 UBML-Designer 的开源，造成社区版低代码平台（Open iGIX）。UBML 代码仓库地址：https://gitee.com/ubml ...

Terraform是一款优良的开源devops工具，中文文档较少，特此整顿Terraform相干内容及应用办法。Terraform是什么？ 在原始的数据中心利用部署中，咱们依赖于运维管理员手动去部署咱们的基础设施和服务，每一台服务器、每一个数据每一个负载平衡都须要手工配置和治理。这些在咱们当初看起来是十分恐怖的，手工带来的谬误配置、迟缓的部署形式都让公司的经营陷入光明，公司的基础设施和服务开始依赖于人的基数增长。好的音讯是计算机领域倒退了多年，devops的概念在公司的经营运维中开始锋芒毕露，当初曾经涌现了很多优良的开源产品，明天要给大家介绍一款功能强大的devops工具：terraform。 Terraform是一款用于平安无效地构建，更改和版本控制根底构造的工具。Terraform能够治理现有数据中心资源和支流云服务提供商资源，以及定制的外部解决方案。 题外话：terraform的母公司HashiCorp在往年5月份进行了包含terraform在内的多款软件企业版的中国使用权，但这不会影响开源产品的应用，在这不想过多介绍其中的起末，只想说开源产品是不属于某一家公司或者国家的，咱们国家也有很多优良的工程师为开源我的项目奉献，开源既是众人拾柴火焰高，也是世界沟通的桥梁，大家能够在平安可控的领域应用开源产品。 言归正传，Terraform是Go语言开发的开源我的项目，github。Terraform次要性能是： 基础设施即代码(Infrastructure as Code)：基础设施是应用高级配置语法来形容的。这样就能够像看待任何其余代码一样对数据中心的蓝图进行版本控制和解决。此外，基础架构能够共享和重复使用。执行打算(Execution Plans)：Terraform有一个“打算”步骤，在其中生成执行打算。执行打算将显示Terraform在您调用apply时将执行的操作。这样能够防止Terraform操纵根底构造时呈现任何意外。资源视图(Resource Graph)：Terraform构建所有资源的视图，并并行化所有非依赖资源的创立和批改。因而，Terraform尽可能高效地构建基础架构，并且操作员能够洞悉其基础架构中的依赖性。变更自动化(Change Automation)：简单的变更集能够以起码的人工干预就能够利用于您的基础架构。应用后面提到的执行打算和资源图，您能够精确地晓得Terraform将要更改的内容和程序，从而防止了许多可能的人为谬误。Terraform能够治理现有数据中心资源和支流云服务提供商资源。具体来说就是能够用代码来治理保护IT资源，把之前须要手动操作的一部分工作通过程序来自动化的实现，这样的做的后果非常明显：高效、不容易出错。它提供了对资源和提供者的灵便形象。该模型容许示意从物理主机、虚拟机、容器、EMail和DNS等所有内容。因为这种灵活性，它能够用来解决许多不同的问题。 这意味着有许多现有的工具与Terraform的性能重叠。然而须要留神的是，Terraform与其余零碎并不互相排挤。它能够用于治理小到单个应用程序或大到整个数据中心的不同对象。 Terraform应用配置文件形容治理的组件(小到单个应用程序，大到整个数据中心)。Terraform会生成一个执行打算，形容它将做什么来达到所需的状态，而后执行它来构建所形容的根底构造。随着配置的变动，Terraform 可能确定产生了什么变动，并创立可利用的增量执行打算。 讲了很多概念当前，大家对Terraform有了一个逻辑上的了解，接下来咱们开始装置Terraform。 Windows10 装置 TerraformTerraform在MAC上装置还是绝对简略的，因为短少中文文档相干介绍内容，在Windows上装置也有踩了一些坑。举荐应用chocolatey进行装置。 装置ChocolateyChocolatey是一款基于Windows的包管理器，装置后能够轻松的像linux的yum、apt-get包管理器一样来治理你的windows中的利用。应用它来装置terraform的益处就是在前期删除降级都由它来治理，这是十分不便和疾速的装置办法。 以管理员身份关上PowerShell，输出Get-ExecutionPolicy，返回Bypass则代表目前执行的是绕过策略来装置。如果返回的是Restricted受限制的，则须要运行Set-ExecutionPolicy AllSigned 或者 Set-ExecutionPolicy Bypass -Scope Process。复制上面这条命令即可装置实现，这里没有太多坑。Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))通过Chocolatey装置Terraform执行命令choco install terraform即可实现装置，两头须要留神： 如果网络不够好，可能存在装置失败，能够至此链接下载https://releases.hashicorp.com/terraform/0.13.3/terraform_0.13.3_windows_amd64.zip后放至C:Users$userAppDataLocalTempchocolateyterraform0.13.3terraform_0.13.3_windows_amd64.zip目录，其中$user为你的以后用户。操作后再次执行命令choco install terraform即可实现装置。装置实现后执行terraform -v可查看以后装置版本，并查看装置胜利。很遗憾的是，没有找到在windows下的命令主动补全办法。 本文作者：UCloud 容器云产品经理 沈旭

我的开源我的项目：酷瓜云课堂 数据库迁徙文件生成用的是开源我的项目：[odan /phinx-migrations-generator](https://github.com/odan/phinx...，最近发现对于MySQL无符号整型（unsigned）并没有正确的生成。 起初我狐疑是MySQL版本的问题，我本地应用的是MySQL8.0，服务器上应用的是MySQL5.7，起初认真查看生成的迁徙问题，外面并没有对于无符号整型（unsigned）的痕迹，那就是相干的包：phinx-migrations-generator 有问题了。 我并没有急着去 baidu 和 google，大抵看了一下phinx-migrations-generator的源代码，找到生成字段的相干逻辑，发现的确存在问题。于是乎我就fork了代码，修复问题（尽管只是改了一行代码），提交 pull request，打完出工。第二天原作者合并了我的提交，收到感激，也算是给开源我的项目做了一点点奉献了（手动开心）。 之前我还给开源我的项目：api-doc 提过一次 pull request，也是小小的批改。 并不是肯定要大牛能力给开源我的项目做奉献，不能深度的参加，咱们就找一个点去参加就好了（小问题，文档，翻译等等）

以下文章来源于36氪Pro ，作者王与桐 小希2016 年 3 月 5 日，北京天气晴。上午 10 点，在一间长十米，宽三米的屋子里，几个身穿格子衫的程序员，开始对着一面白板交换。 这是 PingCAP 第一次 Infra Meetup。这几个人中，有近 10 个来自 PingCAP 的开创团队，唯二的客人，别离是来自华为和京东的开源爱好者。客人比客人多，倒也能够了解，毕竟周六上午的正确打开方式应该是“补觉”。 现在，以交换国内外基础架构技术为主题的 Infra Meetup，曾经举办了一百三十多期。PingCAP 也成为明天成为中国最大的开源社区之一。作为底层软件的公司，PingCAP 独立研发的数据库产品 TiDB，在 GitHub （世界上风行的开源代码托管平台）共计取得超过 25000 的标星，汇合了近 1200 位贡献者（Contributors）；在世界范畴内，TiDB 也是基础架构畛域的出名开源我的项目。 但开创团队的野心却远不止于此，CEO 刘奇说：“咱们还是要专一 TiDB 这一款产品，心愿能够做到 500 亿美元的市值，而这背地须要 10 亿美元量级的营收反对。” 01 商业化：上百付费客户，300% 营收增速500 亿美元市值是什么概念？Oracle 市值 1700 亿美元，Snowflake 市值 700 亿美元。如果要要做到 500 亿市值，须要 10 亿美元量级的营收反对。如何去做营收呢？ 对于开源软件，所有人都关怀的首要问题就是：收费的开源产品，能赚到钱吗？ 先说答案：能。 目前，PingCAP 曾经是中国开源软件畛域营收最高的公司，公司曾经有超过 1500 家用户将 TiDB 用于线上生产环境，国内的客单价在百万元量级，国外更是数倍之高。 中国的开源仍在倒退的晚期阶段，大部分开源厂商尚未开始进行商业化尝试。PingCAP 的商业化跑通让更多的国内的开源公司取得了更疾速的倒退。在开源畛域，头部美元基金也在踊跃布局，比方经纬在近几年也投资了 PingCAP、Nebula 等很多开源公司。 ...

“暑期2020”是由中科院软件所与 openEuler 社区独特举办、中科院软件研究所南京软件技术研究院承办的一项面向高校学生的暑期流动，旨在激励高校在校学生积极参与开源软件的开发保护，促成国内优良开源软件社区的蓬勃发展。 该流动从 5 月份开始，参加流动的学生可自主抉择感兴趣的我的项目，与社区导师沟通实现计划并撰写我的项目计划书。被选中的学生在社区导师领导下，按计划实现开发工作，并将成绩奉献给社区。通过为期 3 个月的开发，流动正式落下帷幕。 此次流动共吸引42家社区、34所高校、388个我的项目退出，这其中不仅有Linux、Apache、CNCF 等国内顶级开源基金会反对的开源我的项目，也有京东等国内顶级企业奉献的开源我的项目。 在本次流动中，京东基于自研的开源我的项目ChubaoFS，设计了开发我的项目，并安顿资深导师与申请者沟通计划，领导学生按计划实现开发。 ChubaoFS是京东自研的云原生存储平台，提供分布式文件系统与对象存储服务，为云原生利用提供计算与存储拆散的长久化存储计划。ChubaoFS 最早于 2017 年在京东外部创立，设计的最后目标是为京东的大型容器集群提供长久化存储的解决方案，同时还能够用作业务端的通用存储。通过长期外部孵化与实际验证，京东将 ChubaoFS 开源募捐给 CNCF，并被 CNCF Storage SIG 工作组列入 Cloud Native Landscape 我的项目。 想理解更多ChubaoFS ，请点击《最适宜云原生的分布式存储平台—— ChubaoFS》查看。 在 5 名获得最佳质量奖的优秀学生中，有一位同学抉择了 ChubaoFS开源我的项目 ，并与社区导师一起设计开发了“基于Rook在Kubernetes集群中部署ChubaoFS Monitor”的我的项目，通过层层筛选，在实现品质、代码的可读性、文档的残缺度使得我的项目具备可延续性等方面失去了社区及组委会的统一认可，获得最佳质量奖。 “暑期2020”为高校学生提供了绝佳的、敌对凋谢的交流平台。使学生能够真正投身于开源软件的开发保护，失去资深开源软件开发者领导的机会，促成开源软件在国内的倒退和优良开源软件社区建设，减少开源我的项目在国内的活跃度，在开源畛域与世界接轨。 ChubaoFS 社区交换： Twitter：@ChubaoFS Mailinglist：chubaofs-maintainers@groups.io Slack：chubaofs.slack.com 举荐浏览： 云原生在京东 | 最适宜云原生的分布式存储平台 — CHUBAOFS云原生在京东 | ASF顶级分布式数据库中间件我的项目 —Apache ShardingSphere云原生在京东 | 揭秘五大云原生我的项目在京东的落地实际欢送点击【京东智联云】，理解京东云原生之路 更多精彩技术实际与独家干货解析 欢送关注【京东智联云开发者】公众号

软件及中间件的装置和配置--第6篇用日志记录“开源软件”的诞生 赤龙ERP开源地址：点亮星标，感激反对，与开发者交换 kzca2000 码云：https://gitee.com/redragon/redragon-erp GitHub：https://github.com/redragon1985/redragon-erp 赤龙ERP官网：https://www.redragon-erp.com 软件装置上一篇刚刚讲了云服务器的搭建，在服务器搭建实现后，紧接着就是装置各种必须的软件、中间件、以及进行必要的优化配置。先说说须要装置的软件及注意事项： （1）JDK装置及环境变量的配置：如何装置JDK以及如何配置环境变量，网络有很多材料，在此不做赘述。只说几个倡议，首先倡议装置JDK而不是JRE，因为JDK的bin目录自带了更多功能组件，其次JDK版本倡议抉择JDK7或8，新版往往因为各种起因不够稳固和继续。 （2）Tomcat装置的版本倡议抉择7或8，依据JDK的对应版本去抉择。装置过程简略无非凡要留神的中央。 （3）MySQl能够抉择最新版，装置时留神端口号和服务名。 （4）Redis能够抉择最新版，Redis默认都是Linux版，如果须要Windows版本，可去GitHub下载：https://github.com/microsofta...。装置时留神端口，装置后最好设置一下开机启动。 Tomcat优化配置网上波及到Tomcat优化的内容很多，人家曾经屡次说过的我不做赘述。我以本人服务器Tomcat配置为案例进行一下简略的剖析： （1）Connector是用于Tomcat建设连贯的，上面做一下简要阐明 <Connector port="80" protocol="org.apache.coyote.http11.Http11NioProtocol" URIEncoding="UTF-8" maxThreads="200" minProcessors="5" maxProcessors="1000" minSpareThreads="25" maxSpareThreads="75" acceptCount="100" connectionTimeout="50000" enableLookups="false" redirectPort="443" compression="on" compressionMinSize="2048" noCompressionUserAgents="gozilla,traviata" compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain" />port是端口，个别对外的服务会改成80protocol是协定，改为NIO，非阻塞式I/O会优化线程的利用率URIEncoding编码UTF-8，防止不必要的乱码maxThreads是用于解决申请的最大线程数acceptCount期待调配线程的连贯的队列数量connectionTimeout连贯超时的毫秒数redirectPort重定向HTTPS协定的端口compression为gzip压缩，肯定水平上能够压缩传输数据的大小（2）SSL协定配置 <Connector port="443" protocol="org.apache.coyote.http11.Http11NioProtocol" URIEncoding="UTF-8" maxThreads="200" SSLEnabled="true" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreType="PKCS12" keystoreFile= "/conf/redragon-erp.com.pfx"keystorePass="123456" />port端口为443SSLEnabled用于HTTPS协定的开启keystore几个参数项用于证书的配置。keystoreFile证书的存储地位，keystorePass证书明码（3）Host用来配置虚拟主机，联合Context实现利用的配置，上面做一下简要阐明 <Host name="www.redragon-erp.com" appBase="webapps" unpackWARs="true" autoDeploy="true"> <Alias>redragon-erp.com</Alias> <Context path="" docBase="F:erp" reloadable="false"/><Context path="caserver" docBase="F:caserver" reloadable="false"/> <Context path="root" docBase="ROOT" reloadable="false"/></Host>Host的name属性配置你的主域名Alias用于多个域名的配置Context用于配置利用，一个利用配置一个Context，path用于配置拜访利用的门路，空代表域名间接拜访以后利用。docBase用于配置利用的门路，能够是相对路径也能够是绝对路径。JVM优化配置JVM优化次要是对内存的优化，间接批改Tomcat启动文件即可，上面说下罕用参数 -Xmx2048m -Xms2048m ：堆内存初始大小和最大内存，如果内存足够倡议间接相等即可 -XX:NewRatio=3 ：新生代和老年代内存比，即1:3，倡议适当调大新生代的占比，缩小垃圾回收次数 -XX:MaxTenuringThreshold=6 ：新生代进入老年代的垃圾回收次数 -XX:+UseConcMarkSweepGC ：设置老年代并发GC-XX:+UseParNewGC ： 设置新生代并发GC-XX:ParallelGCThreads=4 ： 并行GC线程数，与CPU内核数相等 -XX:+CMSParallelRemarkEnabled ：开启并行标记收集 -XX:+UseCMSCompactAtFullCollection ：老年代内存压缩-XX:CMSFullGCsBeforeCompaction=3 ：老年代几次GC后进行内存压缩-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70 ：下面两个配置，示意老年代内存占用70%时GC因为1.8后JVM的永恒代已勾销，而替代者元空间毋庸非凡配置Redis优化配置Redis配置较为简单，次要是明码，连贯，内存和长久化 port 6379 ： 监听端口 requirepass redis ：配置redis用户明码 maxclients 10000 ：设置redis的最大连接数 maxmemory 1024MB ：配置的最大内存容量 maxmemory-policy volatile-lru ：内存容量超过maxmemory后的解决策略（LRU算法） appendonly yes ：应用AOF长久化 appendfsync everysec ：AOF长久化策略的配置（每秒执行一次）JDK装置证书首先要有一个SSL的证书，如何获取证书上一篇已阐明。但有了证书JDK必须实现相应的证书导入能力失效。具体步骤如下： ...

基础设施【硬件】篇--第5篇用日志记录“开源软件”的诞生 赤龙ERP开源地址：点亮星标，感激反对，与开发者交换 kzca2000 码云：https://gitee.com/redragon/redragon-erp GitHub：https://github.com/redragon1985/redragon-erp 赤龙ERP官网：https://www.redragon-erp.com 开源是否须要服务器的反对在聊基础设施前，先聊个简略的话题：开源软件是否须要本人的服务器呢？其实，这要看你对这款开源软件的设定，如果你的目标仅仅是共享一个本人研发的我的项目，而不思考其余的倒退，其实齐全能够只应用GitHub或码云即可。 但如果你想进步软件的知名度，让它应用的更加遍及，并心愿让这款开源软件领有本人的技术社区，同时一直倒退和衍生，那就要配套提供其余的服务，比方软件官网、技术社区、产品体验等，所以服务器、域名等就变得必不可少了。上面咱们就来说说，如何搭建基础设施及注意事项。 云服务器为了能够提供各种服务，首先须要一台服务器，服务器的获取形式多种多样，你能够本人买一台服务器并搭建本人的网络、你也能够间接将服务器托管给第三方，当然咱们当初只谈最简略也最省钱的形式，就是租用云服务器。 云服务器简略了解就是由很多台的物理服务器虚拟化而来。云服务器须要依据你的配置要求去购买，久远思考配置不能过低。以笔者为例，在阿里云购买了四核8G的服务器，另加5G带宽和100G硬盘。我的教训是服务器满足打算需要即可，我之前购买过的年租金1.5W的服务器，配置很高，但有点节约，使用率较低。 上面总结几个购买服务器的关键点： （1）云服务器最重要的性能是CPU和内存，大小肯定要匹配利用的须要，确定好几核CPU、几G内存。我感觉大可不必纠结它外面的各种服务器类型，在同样配置的前提下买最便宜的即可，它们在使用率未达顶峰时的区别微不足道。当然这是对于开源软件的需要而言的。 （2）个别云服务器都会带一块硬盘，用于操作系统。另外可思考再购买一块硬盘用于利用或存储。云盘也有不同的类型，因为开源需要不须要那么高的I/O，所以倡议最便宜即可。 （3）因为开源软件波及的服务，没有什么高并发和高数据传输的服务，对于网络带宽的要求不高。简略的算法带宽除8，再折合你单个申请所波及的数据量和你心愿撑持的并发数，能够做个大略的预估。 （4）操作系统，不论是Linux还是windows，肯定要抉择一个本人相熟的版本，不是非要装置最新版的，这样能够升高出危险的概率。 （5）除了云服务器，不倡议购买任何其余的第三方服务，比方：数据库、中间件等，这些服务根本都是能够本人装置部署的，没必要减少额定的老本。 域名除了服务器以外，至多一个域名也是必不可少的，域名是你的商标，也是一个品牌。域名的注册我也是在阿里云实现的。集体倡议抉择.com域名，在保障与你开源产品名称含意统一的状况下，尽量保障域名的简短及可读性。 购买完域名，紧接着就去实现相应的备案工作。个别域名的服务商会提供备案服务，备案是国家强制并收费的。当初国家对域名备案治理得极其严格，没有备案的域名是无奈应用的。域名备案的周期个别是在两周左右，实现相应的步骤，期待审核通过即可。 证书SSL证书不是必须的，但我集体倡议：值得领有。当初很多中央都有收费的SSL证书，证书的应用能够进步你网站自身的安全性，也能够让用户更加释怀的拜访你的网站（很多浏览器都会标识网站的安全性就是依赖于SSL证书）。 后记到此基础设施局部曾经筹备停当，你曾经具备了根本的硬件环境。下回就开始进入软件及中间件的装置和配置，也顺便补救上一篇文章“技术框架”缺失的那局部内容。 心愿您读完本文能够帮忙笔者进入【码云】或【GitHub】点击星标。期待着您的反对！

作者：Jonathan Cartrette，Zephyr社区成员和Legrand北美IoT零碎技术总监 作为一个物种，咱们曾经发明了对技术的依赖。这种相互依赖发明了数十亿行深度嵌入的、品质参差不齐的代码，这些代码在脱机状态下埋伏了几十年，并领有可能造成毁坏的连接性、传感器和执行器。运行Zephyr OS的大容量/超低功耗Cortex M3-M4或相似大小的RISC-V的资源组合（特地是）提供了我所见过的第一个可扩大的、通明的愿景，将此类设施中所有中央的代码都晋升到异样的代码品质级别。即便它是一个儿童玩具，这些设施有连贯和资源造成挫伤。作为一个社区，咱们必须修改所有的代码。这意味着即便是在嵌入式、连贯产品畛域中“最不重要”的我的项目，也有机会在最好的终点上进步初始代码品质和保护。 为什么？嵌入很深的代码曾经从“靠电线运行（Fly by wire）”转变为“靠算法运行（Fly by algorithm）”，简直没有在行可能意识到其中的奥妙之处。我的意思是，“通过电线运行”个别指的是嵌入式零碎，通常只是简略地传递用意和用户的间接静止，以做一些物理上不可能的事件；像举起一个50英尺长的副翼来反抗500节风速的大风。零碎是相对必要的，它的任何故障，包含性能品质的侵害或成心篡改，都有雷同的结果。然而，在所有状况下，零碎通常无奈对用户输出或阈值触发器作出响应。这并不是零碎意志的失败。 "靠算法运行"另一方面，我指的是这种可能性；一个零碎，其中的性能的足够局部被委托给一个监督数字过程，并容许通知用户“不”。这是一只嵌入了一个非凡的传感器和驱动器群的牧羊犬，用户将会置信这只高贵犬的可靠性。然而当算法“出事”时，咱们失去的是波音737-MAX。当算法攻打零碎时，因为零碎的外在个性，零碎无法访问某些传感器和执行器。这不仅仅实用于飞机，因为这些设施的连通性意味着它们能够间接与咱们生存中的其余设施交互。 Zephyr RTOS给出的答案是：“咱们如何在寰球范畴内进步代码品质？”可怜的是，对很多人来说，这个问题的答案可能是最无趣的话题：开发团队的基本操作效率。LTS（Long Term Support，长期反对版）构建的用意是推动认证，证实血统和起源不会受到烦扰，这不仅仅是为了防止测试和认证工作。随着工夫的推移，提早的认证和测试老本将像滚雪球一样累积。 Zephyr反对这个愿景的起因与工具链和构建零碎无关，甚至与共享库和模块的存储库构造无关。这个社区正在无效地建设一个生态系统，而不仅仅是一个实时操作系统。用于嵌入和深刻代码的DevOps流水线对于软件和固件的保护来说是纯金的高价值，但它们不是新概念。Zephyr OS以这种程度的愿景和品质向社区收费提供这一服务，这是该我的项目愿景的一个证实，在咱们扩充物联网规模时，咱们能够看到须要解决的下一个前沿问题。 点击浏览网站原文。 Zephyr我的项目是一个由Linux基金会托管的合作我的项目，它是一个开放源码合作我的项目，将来自整个行业的领导者联结起来，构建一个最佳的小型、可伸缩、实时操作系统（RTOS），该零碎针对跨多个架构的资源受限设施进行了优化。 Linux基金会是非营利性组织，是技术生态系统的重要组成部分。Linux基金会通过提供财务和智力资源、基础设施、服务、流动以及培训来反对创立永续开源生态系统。在共享技术的创立中，Linux基金会及其我的项目通过共同努力造成了不凡胜利的投资。扫描二维码关注LFAPAC微信公众号。

很多人下载了EduSoho开源版本但不会装置，那么教育机构能如何用EduSoho网校零碎收费搭建网校呢，这里送上官网保姆级EduSoho装置教程+安装包一份，请大家查收！ 装置注意事项： 在装置EduSoho时，请将您的程序运行根目录配置到web下，否则会有课程视频、材料透露等平安问题。即正确拜访您的EduSoho的形式是：http://www.youdomain.com/。如是http://www.yourdomain.com/web/，请依照官网教程批改您的配置。 Ubuntu14.04+Nginx+PHP+MySQL+EduSoho[文档] 留神： 本教程基于Ubuntu零碎 14.04版本并且须要以root用户操作机器，请在确保您的环境是否合乎以上两个条件之后，再进行后续的操作。 切记：咱们的edusoho拜访目录是edusoho/web,只有在nginx或者Apache配置外面把根目录定位到web目录下，才不会呈现奇怪的问题，否则就会呈现图片不能显示或者文件无奈上传的问题。 本教程次要分为一下几个步骤：更新零碎、装置并配置Nginx、装置MySQL、装置并配置PHP、 装置并配置EduSoho，测试Edusoho。 1、更新零碎 sudo apt-get updatesudo apt-get upgrade 2、装置Nginx 2.1 装置nginxsudo apt-get install nginx 2.2 配置Nginxsudo vim /etc/nginx/nginx.conf 而后 在http{} 字段里增加client_max_body_size 1024M; 3、装置并配置MySQL 3.1 装置mysqlapt-get install mysql-server在这个过程过程中会要求您输出MySQL数据库的root明码，请认真填写。 3.2 创立数据库mysql -uroot -p 而后你须要输出MySQL数据库的root明码。进入数据库命令行模式后，创立edusoho数据库，执行： CREATE DATABASE edusoho DEFAULT CHARACTER SET utf8 ; GRANT ALL PRIVILEGES ON edusoho.* TO 'esuser'@'localhost' IDENTIFIED BY 'edusoho';quit;留神：这里为edusoho数据库创立了一个用户名，用户名为：esuser，明码为edusoho，在前面装置的第三步须要用到，不倡议间接填写root账户。 4、装置PHP 4.1 装置PHPsudo apt-get install php5 php5-cli php5-curl php5-fpm php5-intl php5-mcrypt php5-mysqlnd php5-gd ...

很多人下载了EduSoho开源版本但不会装置，教育机构能如何用EduSoho网校零碎收费搭建网校呢，这里送上官网保姆级EduSoho装置教程+安装包一份，请大家查收！ 装置注意事项： 在装置EduSoho时，请将您的程序运行根目录配置到web下，否则会有课程视频、材料透露等平安问题。即正确拜访您的EduSoho的形式是：http://www.youdomain.com/。如是http://www.yourdomain.com/web/，请依照官网教程批改您的配置。 Ubuntu16.04+Nginx+PHP+MySQL+EduSoho[举荐-规范环境-文档] 切记：咱们的edusoho拜访目录是edusoho/web,只有在nginx或者Apache配置外面把根目录定位到web目录下，才不会呈现奇怪的问题，否则就会呈现图片不能显示或者文件无奈上传的问题。 1、更新sudo apt-get updatesudo apt-get upgrade 2、装置nginxsudo apt-get install nginx 2.2 配置Nginxsudo vim /etc/nginx/nginx.conf而后 在http{} 字段里增加 client_max_body_size 1024M; 3、装置php3.1 装置phpsudo apt-get install php-pear php7.0-cli php7.0-common php7.0-curl \ php7.0-dev php7.0-fpm php7.0-json php7.0-mbstring php7.0-mcrypt \php7.0-mysql php7.0-opcache php7.0-zip php7.0-intl php7.0-gd php7.0-xml 3.2 批改配置（PHP上传文件的大小限度）终端输出：sudo vim /etc/php/7.0/fpm/php.ini 批改这三个值的大小post_max_size = 1024Mmemory_limit = 1024Mupload_max_filesize = 1024M 3.3 重启 PHP-FPMsudo service php7.0-fpm restart 4、装置mysqlEduSoho 能够运行在 MySQL 5.5 及以上版本，举荐装置以后最新稳固版本 MySQL 5.7。 下载mysqlsudo apt-get updatesudo apt-get install mysql-server设置明码：在这个过程过程中会要求您输出MySQL数据库的root明码，请认真填写。 ...

很多人下载了EduSoho开源版本但不会装置，教育机构能如何用EduSoho网校零碎收费搭建网校呢，这里送上官网保姆级EduSoho装置教程+安装包一份，请大家查收！对于EduSoho的装置，官网举荐的配置是LNMP,即Linux+Nginx+MySQL+PHP。1、抉择操作系统（Linux） 举荐应用Ubuntu，Fedora，CentOS，Gentoo。2、抉择Web服务器（Nginx或Apache2） Web服务器，官网举荐：Nginx或Apache2。对于Nginx：下载地址： http://nginx.org/en/download....版本举荐： 1.0以上对于Apache2：下载地址： http://httpd.apache.org/downl...举荐版本： 2.0以上3、抉择MySQL数据库MySQL数据库举荐版本：5.0以上。下载地址： http://www.mysql.com/downloads4、抉择PHP版本版本： >= 5.5.0下载地址： http://cn2.php.net/downloads.php留神： Linux 下须要敞开SeLinux ，不然装置实现页面会空白；2.Nginx.conf中肯定要配置client_max_body_size, 不然上传大文会卡住时。EduSoho网络课堂是杭州阔知网络科技有限公司自主研发的一款网校产品，公布于2013年10月，是国内首个开源网校零碎，与Moodle和Open edX并列为世界三大开源在线教育平台产品，能够帮忙培训机构和集体以最低老本、最快速度建设本人的在线教学网站，无需放心技术问题。下期预报：Ubuntu下手动装置EduSoho零碎教程： Ubuntu16.04+Nginx+PHP+MySQL+EduSoho[举荐-规范环境-文档]EduSoho最新开源安装包：http://www.edusoho.com/open/show

如何应用FileZilla的SFTP模式来上传您的文件 1：下载FileZilla 依照您当初操作系统的状态来抉择下载对应的客户端。 下载地址： https://filezilla-project.org..._all=1 2： 设置连贯新站点 关上[文件] -> [站点管理器],呈现一下界面，并依照要求填写。A:主机依照您的IP来填写。 B: 协定抉择SFTP。 C: 登录类型抉择[失常]。 D: 用户名和明码依照您的须要来填写。 E: 如果端口有批改，那么请填写对应的端口 3： 如果呈现申请客户端信赖的对话框，请点击[总是信赖]，并点击[确认]。4：  如果网络不呈现问题的话，您将胜利连贯到你要的服务器上。 另附：保姆级视频转码领导 以下将介绍如何转换出合格的流式MP4文件，供开源网络教学软件EduSoho实现流式播放。本文波及到的软件是格局工厂，具体下载地址：http://www.pcfreetime.com/CN/... 开源网络教学软件EduSoho EduSoho反对的MP4视频编码格局AVC（H264） , 音频编码格局：AAC。 采纳格局工厂转换 1、下载安装格局工厂 2、筹备好须要转换的视频 3、点击转换指标mp4按钮4、弹出对话框点击须要转换的文件，能够一次性抉择多个5、抉择视频文件6、配置转码参数7、具体参数如图配置8、抉择好参数后，点击上述对话框的 ［确定］ 按钮 9、点击开始按钮，开始转换10、利用转换好的EduSoho视频，上传到课时中，能够实现顺滑播放了。 另外，EduSoho提供的云视频套餐外面蕴含了主动转码性能，一旦购买云视频套餐，您就毋庸为转码发愁。 EduSoho的云视频服务提供了弱小的视频转码集群，对视频进行疾速分片转码，并提供不同清晰度的转码后果。 · EduSoho网络课堂是杭州阔知网络科技有限公司自主研发的一款网校产品，公布于2013年10月，是国内首个开源网校零碎，与Moodle和Open edX并列为世界三大开源在线教育平台产品。 · 本系列文章旨在为想要装置EduSoho开源版的教育机构提供帮忙，助力大家低成本搭建网校，发展在线教育。 下期预报：Linux环境下装置EduSoho教程 EduSoho最新开源安装包，自行下载：http://www.edusoho.com/open/show

EduSoho网络课堂是杭州阔知网络科技有限公司自主研发的，国内首个开源网校零碎，与Moodle和Open edX并列为世界三大开源在线教育平台产品。本文心愿为想要装置EduSoho开源版的教育机构提供帮忙，助力大家低成本搭建网校，发展在线教育。 l Apache2.2和2.4的配置区别 apache2.2配置文件： <VirtualHost *:80> ServerName domain.tld ServerAlias www.domain.tld DocumentRoot /var/www/project/web <Directory /var/www/project/web> # enable the .htaccess rewrites AllowOverride All Order allow,deny Allow from All </Directory> ErrorLog /var/log/apache2/project_error.log CustomLog /var/log/apache2/project_access.log combined </VirtualHost> apache2.4和2.2稍有不同，如果您是2.4，将<Directory>节点批改为： <Directory /var/www/project/web> # enable the .htaccess rewrites AllowOverride All Require all granted </Directory> 留神！！！：波及到门路的中央请依照装置教程，批改为本人的门路 EduSoho网校零碎目前曾经服务超过1亿学员，笼罩了寰球120多个国家，基于互联网scrum麻利开发，让每个性能都更易用。 本文内容将继续更新，涵盖EduSoho装置和配置索引、Discuz整合、Web服务器配置、常见拓展装置、FTP工具应用，以及在Linux环境下装置EduSoho、在Windows环境下装置EduSoho和EduSoho二次开发和网站迁徙等方面的操作领导，并给大家提供最新的EduSoho开源版下载安装包，欢送继续关注。 下期预报：常见EduSoho扩大装置教程 EduSoho最新开源安装包，自行下载：http://www.edusoho.com/open/show

云妹导读： “开源软件供应链点亮计划-暑期2020”是由中国科学院软件研究所与openEuler 社区 共同举办的一项面向高校学生的暑期活动，旨在鼓励在校学生积极参与开源软件的开发维护，促进国内优秀开源软件社区的蓬勃发展。京东自研的开源、开放云原生存储平台 ChubaoFS 也加入到了此次项目中，同时针对重要开源软件的开发与维护将提供11个项目，并向全国高校学生开放报名。 01 项目概况“开源软件供应链点亮计划-暑期2020”将联合各大开源社区，针对重要开源软件的开发与维护提供 mini 项目，并向全国高校学生开放报名。学生可自主选择感兴趣的项目进行申请，并在中选后获得该软件资深维护者（社区导师）亲自指导的机会。根据项目的难易程度和完成情况，参与者还可获取“开源软件供应链点亮计划-暑期2020”活动奖金和奖杯。 活动参与方主要角色为学生、社区和导师。 学生：学生自由选择项目，与社区导师沟通实现方案并撰写项目计划书。被选中的学生将在社区导师指导下，按计划完成开发工作，并将成果贡献给社区。社区评估学生的完成度，主办方根据评估结果发放资助金额给学生。社区：社区提供项目列表和描述，并安排项目对应的导师，导师与申请者沟通方案、并从申请者中选中一位承接项目。在为期三个月的开发周期中，导师指导学生进行对应项目的开发工作。导师：社区针对每一个项目指定一个社区导师，与学生一起制定合适的开发计划和方案，指导学生按计划完成开发。02 项目奖金每个项目难度分为高、中、低三档，对应税前奖金分别为高（12000 元）、中（9000 元）、低（6000 元）。（注：奖金数额为税前金额）。 本活动主要针对高校大学生，可访问以下网址了解更多信息：官方活动说明：https://isrc.iscas.ac.cn/summer2020 学生指南：https://isrc.iscas.ac.cn/summer2020/help/student.html 热点问题：https://isrc.iscas.ac.cn/summer2020/help/ 社区邮件列表： liteos@huawei.com 社区官方公共联系邮箱： liteos@huawei.com “暑期2020”项目：https://bbs.huaweicloud.com/blogs/170628 03 关于 ChubaoFSChubaoFS 是京东自研的一个开源、开放的云原生存储平台，提供分布式文件系统与对象存储服务，为云原生应用提供计算与存储分离的持久化存储方案，通过开放的社区形式与全球开发者共建一个开源、开放、多元与包容的生态体系，打造一个拥抱云原生的存储平台。同时 ChubaoFS 社区也是一个技术活跃，鼓励创新，不断开拓技术新方案与最佳实践的平台。 ?社区官网：https://www.chubao.io ?项目地址：https://github.com/chubaofs/open-source-promotion-plan-summer-2020-tasks 扫码进入 ChubaoFS 专属微信交流群 ??? （如无法加入，可在后台回复“ ChubaoFS 社群”） 扫码立即加入直播详情 04 ChubaoFS项目任务ChubaoFS 社区提供的十一个项目任务 项目一项目题目:基于DataFusion和ChubaoFS的存储计算分离 项目描述:在ChubaoFS创建一个基于DataFusion的compute node, 并提供基于ChubaoFS存储节点的SQL服务,使用户可通过SQL在ChubaoFS中存储的非结构化文件中检索信息。 难度: 高 社区项目导师:Dr. Wei Ding 导师联系方式: wei.ding@jd.com 项目产出要求:完成源码开发并且demo基本的SQL操作 项目技术要求：Rust, Go 相关仓库地址: https://github.com/apache/arr... https://github.com/chubaofs 项目二项目题目:基于DataFusion和ChubaoDB的存储计算分离 项目描述:在ChubaoFS创建一个基于DataFusion的compute node并提供基于ChubaoDB的SQL服务。 难度:高 ...

Nebula Graph：一个开源的分布式图数据库。作为唯一能够存储万亿个带属性的节点和边的在线图数据库，Nebula Graph 不仅能够在高并发场景下满足毫秒级的低时延查询要求，还能够实现服务高可用且保障数据安全性。图数据库 Nebula RC1 主要更新本次 RC1 主要增强了 nGQL，新增 LIMIT , GROUP BY 等语句；算法方面增加了最短路径，全路径搜索。 Storage 层新增 PUT/GET 接口，支持 scale out/in，以及新增了 Golang 客户端以及多线程 Golang 数据导入工具。 nGQL新增 LIMIT 指定返回的记录数。(#750)管道操作中支持 YIELD 指定返回类型。(#745)新增 ORDER BY 对结果集进行排序 (#537)新增 udf_is_in 来查询特定集合的数据。(#1096)新增 DELETE VERTEX 删除指定的 vertex 和相关联的出入边。 (#868)新增 UUID() 函数生成唯一值. (#958, #961, #1031)支持逻辑运算符 XOR、OR、AND 和 NOT. (#858)支持 TIMESTAMP 数据类型. (#843)针对 STRING 数据类型，支持更多函数操作，比如 upper(), trim(), lower(), substr() 等. (#841)逻辑运算中支持类型转换 (#964)新增 SHOW CONFIGS 获取指定服务 [meta/storage/graph] 的配置项, GET CONFIGS 获取指定配置项值 and UPDATE CONFIGS 修改配置项值. (#504)SHOW HOSTS 新增 Leader 信息。(#918)支持 FIND PATH 最短路径、全路径搜索 (#847)GO 支持多个 edge types 的图查询。(#699)优化了源代码的编译流程。 (#1047, #948, #1083)Storage新增 PUT/GET 接口. (#977)支持 Leader balance. (#731, #881)支持 HTTP API 获取性能指标。(比如 QPS, Latency AVG/ P99/ P999 等)  (#872, #1136)支持 Scaling out/in。 (#421, #444, #795, #881, #998)Meta client 支持重试, 默认是 3 次. (#814)Tools新增 Golang Importer 工具，支持多线程从 CSV 导入数据.Change更改了 storaged 的配置模板Others将 metad ,  storaged  和 graphd  拆到不同 Image 中。增加 Dockerfiles 创建镜像。 (#923)新增 Golang 客户端，将客户端移到各自的 Repositories 下（vesoft-inc/nebula-go 和 vesoft-inc/nebula-java）。Coming Soon支持数据 Snapshot, 数据回滚功能增强从 Hive 数据导入功能Storage 层支持集群缩容引入 CI/CD附录最后是 Nebula 的 GitHub 地址，欢迎大家试用，有什么问题可以向我们提 issue。GitHub 地址：https://github.com/vesoft-inc/nebula；加入 Nebula Graph 交流群，请联系 Nebula Graph 官方小助手微信号：NebulaGraphbot ...

作者：Dmitri Pavlutin翻译：疯狂的技术宅 原文：https://dmitripavlutin.com/ho... 未经允许严禁转载 你已经为一个有趣的问题工作了几个月，现在决定启动一个开源项目。你在 README.md 中编写了一些说明，并发布了1.0版。 几周后，人们对这个项目仍然没有什么兴趣。你做了大量的工作，付出了最大的努力，但是最后，仍然没有谁对它感兴趣。 怎么会这样？更重要的是，怎样才能使你的开源项目成功？ 我创建了一个开源库 vocajs.com，经过努力，这个库成为了 GitHub 上最受欢迎的项目之一。在这个过程中，我学到了一些重要原则，这些原则涉及如何制作高质量的开源项目。我想要与大家分享这些想法。 1.没人关心你的项目首作为作者，要转变你对开源的看法。你可能会认为，如果你对你感兴趣的项目（库、工具、框架等）投入了大量精力，那么许多人也应该会感到兴奋。 不幸的是，事实并非如此…… 听起来可能很苛刻，但是开发人员仅对解决他们的问题感兴趣。因此，当有人访问你的 github 存储库时，就是在寻找解决方案。 2.解决实际问题甚至在启动开源项目之前，甚至在编写第一行代码之前，都要花大量时间去寻找要解决的实际问题。 总而言之，一个好的开源项目解决了开发人员正在积极寻求解决方案的问题。 根据我的经验，我决定写一个 JavaScript 字符串库。我的主要理由是当时的解决方案质量低下。另外 JavaScript 本身没有全面的标准字符串库。 我对字符串并不特别热衷，创建这样的库甚至可能很无聊……但是更重要的是，我发现了一个需要解决的问题。 寻找问题要用到的一些策略： 思考你遇到的问题。你可以为此创建解决方案吗？探索被广泛使用但性能中等的开源项目。可以实施自己的更好的解决方案。在 GitHub 的热门项目、Stackoverflow 问题甚至 Twitter 问题中搜索想法。关键点???? 成功的开源项目解决了一个已知的问题3. 强调质量大多数开发人员都在闭源项目中工作。除了你的队友以外，很可能有一些开发人员会阅读你的代码。 但是，当你为所有人开放代码时，情况就不同了。 事实是，很多开源代码并不是最好的质量。没人会依赖于难以理解、不稳定且充满错误的代码去解决问题。 这方面是增加信任度并证明你的开源项目正在测试质量的好方法。你可能需要至少 80％ 的代码覆盖率。 你甚至可以走得更远，并在 README.md 上放一些标记，以证明代码库已经过全面测试。 源代码的可读性也是一个重要方面。如果你想在以后的阶段吸引更多的贡献者，则代码必须易于阅读且结构合理。 此外，开源工具将只从实现非功能性需求中受益： 有直观、可配置和可扩展的 API支持广泛的环境（跨平台，跨浏览器等）提供选择功能的可能性几乎没有依赖关系体积小关键???? 成功的开源项目具有高质量代码和高代码覆盖率4.优秀的 README.md 和文档好，你遵循了我的建议，发现了一个不错的问题，并实施了一个相对不错的解决方案。这就够了吗？ 不幸的是，只完成了一半的工作…… README.md 文件是项目的入口点。而且，如果你不能简洁明了地解释项目的确切目的，人们将几乎不了解它的任务。 如果 README.md 缺少详细信息，你可能会认为开发人员慧深入研究实现细节，并自行找到如何使用该工具的方法。通常，这种情况不会发生，因为没人喜欢解密代码。 每个人的期望是了解你的工具可以解决什么问题以及如何使用它。就这样。 告诉你一个对我有效的真理： 花 50％ 的时间编写引人注目的 README.md 和简单明了的文档。是的，你没有看错。花一半时间解释项目的用途以及如何使用它。 4.1 README.md用户在访问项目存储库时最先看到的是 README.md 文件。你只有20-30秒的时间吸引注意力去兜售你的东西。 ...

Nebula Graph：一个开源的分布式图数据库。作为唯一能够存储万亿个带属性的节点和边的在线图数据库，Nebula Graph 不仅能够在高并发场景下满足毫秒级的低时延查询要求，还能够实现服务高可用且保障数据安全性。Nebula Graph v1.0.0-beta 版本已发布，更新内容如下: Storage Engine支持集群部署引入 Raft 一致性协议，支持 Leader 切换存储引擎支持 HBase新增从 HDFS 导入数据功能查询语言 nGQL新增注释功能创建 Space 支持默认属性，新增 SHOW SPACE 和 DROP SPACE 功能新增获取某 Tag 或 EdgeType 属性功能新增获取某 Tag 或 EdgeType 列表功能新增 DISTINCT 过滤重复数据新增 UNION ， INTERSECT 和 MINUS 集合运算新增 FETCH 获取指定 Vertex 相应 Tag 的属性值WHERE 和 YIELD 支持用户定义变量和管道操作WHERE 和 YIELD 支持算术和逻辑运算新增 ORDER BY 对结果集排序支持插入多条点或边支持 HOSTS 的 CRUD 操作Tools新增 Java importer - 从 CSV 导入数据package_build -  支持 Linux 发行指定版本的软件包perf tool - Storage Service 压测工具Console 支持关键字自动补全功能ChangeLog$$[tag].prop` 变更为 `$$.tag.prop ， $^[tag].prop 变更为 $^.tag.prop 重构运维脚本 nebula.service附录最后是 Nebula 的 GitHub 地址，欢迎大家试用，有什么问题可以向我们提 issue。GitHub 地址：github.com/vesoft-inc/nebula  ；加入 Nebula Graph 交流群，请联系 Nebula Graph 官方小助手微信号：NebulaGraphbot ...

2019 年 6 月 25 日，全球知名开源组织云原生计算基金会 CNCF 宣布，蚂蚁金服正式成为 CNCF 黄金会员，蚂蚁金服表示将持续加大对开源项目的支持，包括 Kubernetes，ServiceMesh，Serverless，安全容器等方向，并发挥自己的力量。SOFAStack 作为蚂蚁金服重要的开源项目，最近也与 CNCF 有故事发生。近期，CNCF 发布了最新版本的 Cloud Native Landscape，蚂蚁金服金融级分布式架构 SOFAStack 中有 3 个项目被纳入，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。 CNCF & CNCF Cloud Native LandscapeCNCF(Cloud Native Computing Foundation)，是由 Google 牵头创立的云原生计算开源软件基金会。它致力于云原生(Cloud Native)技术的普及和可持续发展。2016 年 11 月，CNCF 开始维护 Cloud Native Landscape，汇总流行热门的云原生技术与工具，并加以分类，为企业构建云原生体系提供参考，在云生态研发、运维领域具有广泛影响力。 SOFAStack & CNCF Cloud Native Landscape蚂蚁金服金融级分布式架构 SOFAStack 中的 3 个项目加入这次最新版本的 Cloud Native Landscape ，分别是 Service Mesh 数据平面代理 SOFAMosn、分布式链路跟踪系统 SOFATracer 和 RPC 服务框架 SOFARPC。 ...

有没有遇到这样一种情况，你花了很大精力在业务项目中写了一个组件，你觉得这个组件很通用，除了当前的业务场景还应该有其他的应用场景，所以你想开源这个组件，但又不知道从何入手。这篇文章就来聊聊如何开源一个前端组件，无论是业务中已有的组件还是新的组件。 1. 初始化1.1 Git可以在 Github 上新建一个项目，这里取名 "component-example"，然后使用 git clone 命令克隆到本地进行开发。也可以先在本地建好文件，然后使用 git remote add 命令将本地项目与远程项目进行绑定。 1.2 NPM进入项目根目录，执行 npm init 命令初始化项目，这里没什么注意点，一路默认即可，命令执行结束后会得到一个 "package.json" 文件。 1.3 React在项目根目录新增 "src" 文件夹，进入 "src"，新建 "index.js"、"index.css"、"App.js" 和 "App.css" 4 个文件。 "index.js" import React from 'react';import ReactDOM from 'react-dom';import styles from './index.css';import App from './App';ReactDOM.render(<App />, document.getElementById('root'));"APP.js" import React from 'react';import styles from './App.css';export default class APP extends React.Component { render() { return <div>Hello, React Component！</div> }}安装 react 和 react-dom： ...

一、环境准备已安装Apache Spark 2.2.0(此版本仅支持Apache Spark 2.2.0, 其他Spark 版本后续会兼容)已安装MySQL并启动,且开启远程访问各安装节点已经配置ssh免密登录二、下载moonbox-0.3.0-beta下载：https://github.com/edp963/moo... 三、解压tar -zxvf moonbox-assembly_2.11-0.3.0-beta-dist.tar.gz四、修改配置文件配置文件位于conf目录下 step 1: 修改slaves mv slaves.example slaves vim slaves将会看到如下内容: localhost请根据实际情况修改为需要部署worker节点的地址, 每行一个地址 step 2: 修改moonbox-env.sh mv moonbox-env.sh.example moonbox-env.sh chmod u+x moonbox-env.sh vim moonbox-env.sh将会看到如下内容: export JAVA_HOME=path/to/installed/dir export SPARK_HOME=path/to/installed/dir export YARN_CONF_DIR=path/to/yarn/conf/dir export MOONBOX_SSH_OPTS="-p 22" export MOONBOX_HOME=path/to/installed/dir # export MOONBOX_LOCAL_HOSTNAME=localhost export MOONBOX_MASTER_HOST=localhost export MOONBOX_MASTER_PORT=2551请根据实际情况修改 step 3: 修改moonbox-defaults.conf mv moonbox-defaults.conf.example moonbox-defaults.conf vim moonbox-defaults.conf将会看到以下内容,其中: catalog配置元数据存储位置, 必须修改, 请根据实际情况修改 rest配置rest服务, 按需修改 tcp配置tcp(jdbc)服务, 按需修改 ...

一、导语『洞察』是宜信安全部开发，集成应用系统资产管理、漏洞全生命周期管理、安全知识库管理三位一体的管理平台。 应用系统资产管理：对公司应用系统资产进行管理，包括系统名称、域名、重要级别、部门、负责人等。漏洞生命周期管理：对公司应用系统产生的安全漏洞进行线上提交、通告、知悉、复测、分类、风险计算、修复期限计算、邮件提醒、漏洞数据分析统计等。安全知识库管理：对安全知识、管理制度进行集中存放、线上学习、安全培训、知识传承等。『洞察』使用了Python语言进行开发，利用Flask框架+MySQL+Docker部署实现。 洞察界面截图如下： 二、设计理念应用安全管理从应用资产的风险评估开始，公司资产一旦多了之后，往往会面临资产不清晰、找不到负责人、漏洞持续跟踪成本高昂、安全知识难以沉淀、高频风险没有数据支持、不能有的放矢的解决核心问题，另外风险量化也是难题。 应用安全管理体系设计中，风险治理一般过程如下： 基于上述风险治理的实际需求，『洞察』应运而生。 三、平台亮点使用『洞察』系统后，我们实现了以下目标，请看大图： 历史漏洞一目了然 漏洞跟踪有条不紊 学习案例信手拈来 安全要求精准管控 威胁风险有理有据 量化数字实时知晓 四、使用指南平台用户分为以下5种角色 匿名用户：公司内部未登录用户普通用户：普通登录用户，指公司研发、业务、产品经理等。安全人员：安全部门进行漏洞测试、提交、跟踪修复的人员等。安全管理员：安全部门对漏洞进行审核的管理人员。超级管理员：最高权限账号，对用户的角色进行分配。以上5种角色对应的使用文档请见： 使用指南-匿名用户篇：https://github.com/creditease... 使用指南-普通用户篇：https://github.com/creditease..._user.md 使用指南-安全人员篇：https://github.com/creditease..._user.md 使用指南-安全管理员篇：https://github.com/creditease..._manager.md 使用指南-超级管理员篇：https://github.com/creditease..._user.md 五、项目地址OWASP项目地址 洞察-宜信漏洞管理平台目前已被OWASP S-SDLC项目组正式收录，更多英文版详情请见OWASP S-SDLC项目地址： https://www.owasp.org/index.p..._Secure_Software_Development_Lifecycle_Project#tab=Main https://www.owasp.org/index.p..._Secure_Software_Development_Lifecycle_Project#tab=Related_stuffs GitHub开源地址：https://github.com/creditease... 内容来源：宜信技术学院

导读：业务系统或者日志系统产生了大量的原始数据，我们根据业务场景需求将数据保存到不同的存储中。然而，数据只有通过整合、加工、计算，才能提取出其潜在的信息，让数据变为资产，从而实现数据的价值。Moonbox就是这样一款计算服务平台，在敏捷大数据（Agile BigData）理论的指导下，围绕“计算服务化”和“数据虚拟化”两个核心概念进行设计，支持多种数据源混合计算。Moonbox的设计理念是怎样的？又有什么功能特点呢？本文带您初步走进Moonbox~ 开源地址：https://github.com/edp963/moo... 一、Moonbox设计理念大数据技术在企业中的应用日益广泛，为解决各种不同的场景问题，越来越多的数据系统出现，而如何基于全景数据去进行快速查询计算成为了迫切的需求和挑战。 目前的主流方式是建立以Hadoop为核心的数据仓库/数据湖，这在某种程度上解决了异构数据系统及数据分散的问题，但依然存在数据归集带来的维护成本和时效损失。另外，数据开发人员也面临着业务频繁变更和结果快速交付的问题。 面对这一系列挑战，计算服务化和数据虚拟化提供了很好的解决思路。Moonbox正是在大数据场景下，对计算服务化和数据虚拟化的一种实践，其设计思想主要体现在以下几个方面： 1、计算服务化Moonbox提供多种查询接口以及定时任务，将计算资源变成一种服务，终端用户可以自助注册数据源编写SQL实现需求，只需要关心业务逻辑，而不用关心作业是如何提交运行的。 2、数据虚拟化Moonbox提供虚拟表到物理表之间的映射，终端用户无需关心数据的物理存放位置和底层数据源的特性，可直接操作数据，体验类似操作一个虚拟数据库。 3、统一入口✔ 统一查询语言 Moonbox对用户提供统一的SQL语法标准，屏蔽异构数据系统查询语言的差异，用户只需编写SQL即可查询各种数据系统，也可使用SQL进行跨异构数据系统混算，降低多数据系统的学习成本。 ✔ 统一元数据服务 Moonbox能够对接多种数据系统，可以拿到各个数据系统数据表的schema信息，Moonbox并不存储schema信息，每次都是实时从数据源获取，所以不存在元数据变更不及时，需要同步更新等问题。Moonbox对外提供统一的元数据服务接口，用户无需为了获取各种数据源的元数据而调用多种接口。 ✔ 统一权限控制 每种数据源都有各自特有的安全机制，用户在使用这些数据系统的时候就需要多付出一定的学习成本。Moonbox在逻辑层提供了统一的安全访问机制，在接入时，提供认证登录功能；在查询时，通过拦截分析查询SQL，实现列级别的数据权限控制。如果查询统一从Moonbox接口进入，那么Moonbox就为各种数据源加上了一把安全锁，用户无需再学习各种数据源特有的安全机制。 二、Moonbox体系架构Moonbox体系架构图如下： Moonbox总体上由四部分组成，分别是Moonbox客户端、Moonbox接入层、Moonbox核心功能层以及存储计算层。 1、Moonbox客户端Moonbox客户端主要包括以下几种： ✔ restful api 以restful api的方式提供计算服务，支持batch、adhoc模式，支持同步和异步方式。 ✔ jdbc 对jdbc接口的实现，使用户拥有数据库般的使用体验。 ✔ cli 命令行工具，基于jline实现。通过cli可以完成DDL(Data Definition Language)、DML(Data Manipulation Language)、DCL(Data Control Language)以及Query操作。 ✔ zeppelin 提供zeppelin moonbox interpreter，可以使用zeppelin快速进行原型验证和SQL开发。 ✔ davinci 通过jdbc支持ABD Stack（敏捷大数据技术栈）中数据可视化平台davinci的接入，进行数据查询并展示。 2、Moonbox接入层接入层包括http server和tcp server，实现客户端接入，并进行用户登录认证，支持内置用户名密码认证方式和ldap集成认证方式。 3、Moonbox核心功能层Moonbox将其核心功能层命名为Grid。Grid使用master-slave集群工作模式，支持master主备切换。 Grid有Master、Worker、Runner三种角色： ✔ Master Master负责接收所有的用户请求，根据请求模式(adhoc/batch)将请求调度到合适的Worker上。 ✔ Worker Worker负责Runner的生成和销毁，将请求分配给合适Runner。 ✔ Runner Runner处理用户发过来的请求，包括用户体系管理操作、权限管理操作、SQL解析、下推优化、执行引擎选择等，并向存储/计算层提交真正的计算任务。 4、存储/计算层存储/计算层是计算真正发生的地方。Moonbox使用Spark作为混算引擎，支持standalone和yarn运行模式。当计算逻辑可以完全下推到数据源计算时，Moonbox将计算任务直接mapping成数据源的查询语言进行下推计算，以减小启动分布式作业的开销。数据源除了可以是hdfs这种纯存储系统，或者mysql、elasticsearch这种带计算能力的存储系统，还可以是presto等计算引擎，Moonbox将他们统一视为数据源。 三、Moonbox功能特点1、用户体系Moonbox建立了一套完整的用户体系，引入了Organization的概念，用于划分用户空间。系统管理员ROOT账号可以创建多个Organization，并在Organization中指定该Organization的管理者（SA）。SA可以是一个或者多个，负责创建管理普通用户。 Moonbox将普通用户的能力抽象出五大属性，分别为： ✔ 是否可以创建新用户 ...

导读：在上一篇文章「Wormhole 大数据流式处理平台之设计思想」中，我们介绍了Wormhole的设计思想，并给出了Stream、UMS、Flow、Namespace等相关概念的具体定义，从文章中我们得知，Wormhole作为实时流式处理平台，其设计思想最终是为流上处理数据而服务的。在本文中，我们主要从Wormhole的功能设计入手，重点介绍Wormhole所支持的几个基本功能。 Wormhole支持的功能很多，如图1所示，除了流式数据处理，Wormhole在管理和运维等方面也做的比较完善。下面我们从流式处理、平台管理、数据质量、数据安全以及运维监控五个维度来介绍Wormhole的具体功能。 一、流式处理Wormhole的核心是流式处理，并将流式处理抽象为Flow（流式处理逻辑管道，具体参见：#Wormhole# 流式处理平台设计思想）。Flow的引入，使得一个Spark Streaming上可以跑不同的处理逻辑，也就是多个Flow可以在一个Spark Streaming上同时执行而互不影响。这种异构逻辑的并行处理大大提高了资源利用率，也提高了流式处理的易用性。 如图2所示，Flow从处理过程角度分为解析、转换、写入三个过程，具体如下： 1.1 解析Flow支持多种消息协议，UMS和用户自定义JSON两种消息协议： UMSUMS是Flow支持的标准消息协议，在设计思想的文章中有介绍，这里不再介绍。（参见：#Wormhole# 流式处理平台设计思想） 自定义JSON开源后，为了适配用户已有系统的数据格式需求，Flow开始支持用户自定义JSON消息协议，使用也比较方便简单，只要在页面贴一个JSON消息例子，就会自动解析，然后通过点击配置即可完成自定义JSON的Schema的定义。 1.2 转换这里的转换主要指对流上指定的Namespace的数据进行处理，处理方式包括Transform SQL（包含Spark SQL、Lookup SQL、Stream Join SQL）和接口扩展等，并且所有操作都可以有多项，即一个Flow中可以有多个Spark SQL，多个Lookup SQL，多个接口扩展等，具体如下： Spark SQL利用Spark天然支持的SQL对数据做一些map操作，用户指需要在页面编写SQL即可实现实时对流上数据的Spark SQL处理。 Lookup SQLLookup SQL是指将流上指定Namespace数据按某个或某几个字段join外部实体数据系统的数据，也就是将流上的数据加列处理，在页面编写SQL即可实现对流上数据的Lookup操作。目前支持多种Lookup SQL数据系统，包括Mysql、Oracle、Postgresql、SQLServer、Cassandra、Mongodb、Phoenix、ElasticSearch、Vertical、KUDU、Redis、Hbase，除了Redis和Hbase写法是类SQL写法之外，其他都支持SQL写法。下面举例介绍SQL的编写： ✔ 单字段关联： select col1, col2, … from tableName where colA in namespace.X; ✔ 多字段关联： select col1, col2, … from tableName where (colA,colB) in (namespace.X,namespace.Y); ✔ Redis 因Redis不是结构化存储方式，所以只能模仿SQL写法： Redis的value是字符串时：select name:type as n1 from default(simple) joinby (key1+'_'+key2); ...

互联网技术发展速度之快是所有从业者甚至非从业者都能感受到的。尤记得在世纪之交时，那时候互联网刚刚在中国开始向民用普及，不说支撑大规模的网站访问量的相关技术，就连 Linux、负载均衡甚至都没有被普遍使用。而在二十年之后，云计算已经大行其道，当今的技术人员已经言必称虚拟化、容器和 Serverless，就连刚刚准备入行互联网运维行业的新人们都已经从最初觉得考个 Linux 认证就够了到开始问询 Kubernetes 培训哪家强了。 从一届届 LC3、DockerCon 到 KubeCon，蓬勃发展的云计算与容器化似乎已经称霸了互联网领域。这次我带队参加了 6 月 24 ~ 26 日的 KubeCon 大会，对此感受尤为深刻。事实上，这次在上海举办的 KubeCon 2019 距离上次在同一地点举办的同一会议才仅仅过去半年，但是我们依旧在这次大会上看到了层出不穷的大量新技术、新动态。 云与容器的结合，引爆了这一切。作为容器领域的资深专家，让我们来看看王旭是如何看待容器和云原生领域当前的发展态势的，以及作为这个领域的一家初创技术企业的创始人，他是如何投身到这个领域的，开源又在其间起到了什么作用。 创立于 2015 年的 runV 项目已于 2017 年和另外一个来自英特尔的 Clear 容器项目合并为 Kata 容器项目，并由 OpenStack 基金会（OSF）进行管理，它与来自谷歌的 gVisor 项目并称为目前两大安全容器技术。 开源与初创要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。临近 2015 年，Docker 逐渐被业界主流所接受，互联网技术已经有一个比较明显的发展趋势：第一是云，第二是容器。而云加上容器一定会产生隔离性的需求，这应该说是王旭和他的联合创始人赵鹏做安全容器最早的一个思路：要么就去加强容器，要不就是引入别的安全技术来让它像容器一样。这就是 runV 这个项目想法的起源。 runV 发布的同一个星期，英特尔Clear 容器也发布了。2016 年 8 月份，在西雅图的 LinuxCon 上，王旭和 Clear 团队见面交流，双方在一些细节上面展开合作。在 2017 年 9 月份一个会议上，英特尔软件副总裁、开源技术中心总经理 Imad Sousou 提出项目合并，然后放到基金会里管理。当时大家都觉得这是很好的一个思路。 对于 runV 和 Clear 来说，避免了重复开发以及花费精力在如何说明两者的不同上，同时合并之后可以共同推动发展一个社区，一起去寻找更多的用户。同时，两者合并还有更多的意义。 ...

导读：通过图形化手段清晰地传达数据，促进信息的传递与沟通，是数据可视化的基础要素，也是设计美学和功能相结合的具体表现形式。Davinci便是这样一款可视应用平台。在敏捷大数据（Agile BigData）理论的背景下，围绕“数据视图”和“可视组件”两个核心概念设计，支持多种可视化功能。Davinci具体的设计理念和功能特点都有什么呢？它又将怎么成长呢？让我们一起来阅读本文吧~ 一、Davinci背景介绍在现代商业中，大数据扮演着越来越重要的角色，企业在数据分析和呈现上逐渐青睐于数据可视化工具，这类工具往往能有效地帮助使用者： 回顾大量数据 决策者通过查看以图形形式呈现的数据，能够在短时间内有效地理解大量数据的意义，相比分析数据表格要快得多。 发现趋势 时间序列数据通常蕴含趋势，但是当数据源种类繁多、数据量巨大时，发掘出隐藏在数据中的趋势便很难实现了。使用恰当的大数据可视化技术可以很容易地发现这些趋势，从而支持商业中更加快速和精准的决策。 识别相关性和意外的关系 大数据可视化的一个巨大优势是它可以让用户自由探索数据集，这并非为了寻找某个问题的特定答案，而是去挖掘数据所能带来的出人意料的结论。在数据中识别出以往未被重视的模式和关系可以为企业提供巨大的竞争优势。 友好地数据呈现 大数据可视化有一个经常被忽视的特性：它往往提供了一种非常有效的方式来传达他人对数据的的发掘成果，因为使用图形化的方式传达信息更容易被理解。 然而，在可视化工具的选择中，我们经常会陷入功能性和易用性的困境。功能强大如老牌数据可视化软件 Tableau、PowerBI 等，想要上手的话需要了解不少概念，当熟悉教程之后，想要与同事或朋友们分享可视化成果，又面临着众多 license 的选择。在使用一些第三方数据可视化平台时，又不免会有一些对数据隐私性的担忧。如果放弃使用成熟的软件和平台，自己去搭建一个可视化工具，可是需要有编程能力的。那么有没有一个数据可视化软件既可以上手简单、开源免费，又提供丰富的可视化功能呢？说到这里，就轮到Davinci出场了。 二、Davinci是什么Davinci 是一个DVAAS（Data Visualization as a Service）平台解决方案，面向业务人员/数据工程师/数据分析师/数据科学家，致力于提供一站式数据可视化解决方案。既可作为公有云/私有云独立使用，也可作为可视化插件集成到三方系统。用户只需在可视化UI上简单配置即可服务多种数据可视化应用，并支持高级交互/行业分析/模式探索/社交智能等可视化功能。 模块架构： 三、Davinci 设计理念围绕 View（数据视图）和 Widget（可视组件）两个核心概念设计 View是数据的结构化形态，一切逻辑/权限/服务等相关都是从View展开Widget是数据的可视化形态，一切展示/交互/引导等都是从Widget展开作为数据的两种不同形态，二者相辅相成，让用户拥有一致的体验和认识。 强化集成定制能力和社交智能能力 集成定制能力指无缝集成到三方系统，并提供强大的定制化能力，使其和三方系统融为一体。社交智能能力指共享优秀的数据可视化思想，激发用户对数据可视化表达能力和艺术美感的追求，同时也使Davinci更加智能的引导和提高用户的数据可视化能力。社交智能能力指共享优秀的数据可视化思想，激发用户对数据可视化表达能力和艺术美感的追求，同时也使Davinci更加智能的引导和提高用户的数据可视化能力。 四、Davinci 功能特点数据源 支持JDBC数据源和CSV文件上传 数据模型 支持友好 SQL 编辑器进行数据处理和转换支持自动和自定义数据模型设计和共享数据视图 支持定义SQL模版、SQL高亮显示、SQL语法测试和回写操作 可视化组件 支持基于数据模型拖拽智能生成可视化组件支持各种可视化组件样式配置支持自由分析能力 数据门户 支持基于可视化组件创建可视化仪表板支持可视化组件自动布局支持可视化组件全屏显示、本地控制器、高级过滤器、组件间联动、群控控制器可视组件支持可视化组件大数据量展示分页和滑块支持可视化组件 CSV 数据下载、公共分享授权分享以及可视化仪表板的公共分享和授权分享支持基于可视化仪表板创建数据门户 数据大屏 支持可视化组件自由布局支持图层、透明度设置、边框、背景色、对齐、标签等更丰富大屏美化功能支持多种屏幕自适应方式用户体系 支持多租户用户体系支持每个用户自建一整套组织架构层级结构支持浅社交能力集成能力 支持安全 URL 嵌入式集成支持 JS 融入式集成安全权限 支持 LDAP 登录认证支持动态 Token 鉴权支持细粒度操作权限矩阵配置支持数据列权限、行权限五、场景支持安全多样自助交互式报表 一次配置即可实现可视组件高级过滤、高级控制、联动、钻取、下载、分享等，帮助业务人员快速完成对比、地理分析、分布、趋势以及聚类等分析和决策。 自动布局的 Dashboard（仪表板），适用于大多数通过快速配置即可查看和分享的可视化报表。 自由布局的 Display（大屏），适用于一些特定的、需要添加额外修饰元素的、长时间查看的场景，通常配置这类场景需要花一定的时间和精力，如“双11”大屏。 ...

导读：互联网的迅猛发展使得数据不再昂贵，而如何从数据中更快速获取价值变得日益重要，因此，数据实时化成为了一个大趋势。越来越多的业务场景需要实时分析，以极低的延迟来分析实时数据并给出分析结果，从而提高业务效率，带来更高价值。流式处理作为实时处理的一种重要手段，正在因数据实时化的发展而蓬勃发展。本文是敏捷大数据（Agile BigData）背景下的实时流式处理平台Wormhole的开篇介绍：Wormhole具体是一个怎样的平台？ 开源地址：https://github.com/edp963/wor... 一、Wormhole背景介绍在流式计算领域，越来越多成熟的技术框架出现在开源世界，如Storm、Heron、Spark、Samza、Flink、Beam等。流式技术也逐步进化发展，支持流上丰富计算语法（类SQL）、支持at least once或exactly once语义、支持高可靠高可用、支持高吞吐低延迟、支持基于事件时间计算、支持统一整合接入抽象等，这些都从不可能变为可能。 然而，虽然流式处理的技术已经很丰富，流式处理在企业中的实施仍然存在较大难度，主要原因是成本高，需求上线周期长等，而产生这样问题的原因又分两个方面，一是企业组织结构，二是技术。 传统数据仓库和BI的组织结构都是集中相关技术人员成立独立大数据部门，各个业务部门向其提需求，做定制化开发。 （企业组织结构） 如上图，大数据部门不仅仅做大数据环境运维，还做定制化开发和线上业务维护。恰恰这两点会消耗大量的人力，也增加了管理和沟通成本。举一个需求开发的例子，如下图： （需求开发流程） 上图是企业普遍使用的一个开发流程，这里边就反应出一些问题： 人力成本高从此图可以看出，至少需要3个角色的人员才能完成一个需求，而且流式开发人员要花很多时间了解需求、业务、表结构等等。 上线周期长、效率低所有需求都是由产品人员提出，由业务人员分析，然后与流式开发人员一起设计开发完成，且需要大量时间测试及验证结果。 复用低在需求中，有很多业务是类似的，但因业务和定制化问题，所以无法很好的做到代码复用，导致重复开发比较多。 业务维护成本高当上线的需求有变化时，就要在原有代码的基础上改造，流式处理开发人员也需要再一次了解业务流程、表结构等等，还是需要很多的人力资源，并且周期也很长，同时改动会增加出问题的概率。 大量消耗资源为了功能隔离和降低维护难度，每个定制化功能都要启动一个流式应用，无法复用，需要占用大量硬件资源。 目前流式处理的种种问题很大的制约了企业实时大数据的发展，各个公司都在寻找一条更轻量的解决之道。我们根据多年在实时大数据项目中的实践和经验积累，自主研发了流式处理平台——Wormhole，很大程度上解决了上述各类问题。下面我们来介绍一下Wormhole的具体情况。 二、Wormhole是什么Wormhole是一个面向实时大数据项目实施者的流式处理平台，致力于统一并简化大数据开发和管理，尤其针对典型流式实时/准实时数据处理应用场景，屏蔽了底层技术细节，提供了极低的开发门槛。项目实施者只需简单配置及编写SQL即可支持大部分业务场景，使得大数据业务系统开发和管理变得更加轻量、可控可靠。 （Wormhole数据处理样例） Wormhole主要基于Spark技术，实现了基于SQL的流上数据处理和异构系统幂等写入等相关功能。如上图所示，Wormhole接入流上的数据，然后将数据中的出生日期通过用户编写的SQL处理为年龄，写入到另外一个存储系统中。 Wormhole通过技术手段实现基于SQL的流式处理方案，大大降低了流式处理的技术门槛；同时通过平台化和可视化等实现了职能的变化，减少了整个需求生命周期的参与角色数量，精炼了整个开发过程，进而缩短了开发周期，也减少了开发和维护成本。 三、Wormhole设计目标3.1 设计目标基于敏捷大数据的思想，Wormhole的设计目标如下： 平台化/组件化通过平台化支持，组件化组装实施，可以快速对原型进行验证，和需求方形成反馈闭环快速迭代 标准化对数据格式进行标准化，达到通用效果，减少数据格式化和维护的成本 配置化/可视化用户可视化配置、部署、管理、监控，降低大数据产品开发门槛，确保高质量产出 低延迟/高性能/高可用根据实时性的要求，流式处理要求更低的延迟，并且要求更高的吞吐量，以及容错能力，保证系统7*24正常运行 自助化/自动化让企业从数据中心化转型为平台服务化，让每个数据从业者都能够有更多的自助服务，并释放数据处理能力，系统替代人工完成重复低级的工作，让从业者回归数据和业务本质 3.2 效果体现Wormhole平台的建设带来的效果主要体现在以下几方面： 组织结构更合理：如下图，大数据相关部门不再做定制化开发和业务维护，而是更专注平台化和大数据环境的稳定，大大减少了人力资源的浪费。 （基于Wormhole的组织结构） 降低了流式处理开发的技术门槛：流式处理的开发模式变为了业务人员通过可视化配置和编写SQL即可完成80%以上的业务场景，不再需要对流式处理技术有很深的理解 缩短了需求上线周期：如下图所示基于Wormhole的需求开发流程，一个需求从提出到上线只需要产品人员和业务人员，大幅降低了沟通和学习成本，进而大大缩短了需求开发上线周期。 四、Wormhole设计规范 （Wormhole流程设计图） 上图是Wormhole的一个设计介绍，体现了流式处理的从输入到输出的过程，在这个过程中，Wormhole定义新的概念，将整个流式处理进行了标准化，将定制化的流式计算变为标准化的流式处理，并从三个纬度进行了高度抽象。 统一数据逻辑表命名空间——NamespaceNamespace：数据的“IP”，通过7层结构唯一定位数据对应的物理位置，即 [Data System].[Instance].[Database].[Table].[Table Version]. [Database Partition].[Table Partition] 1）统一通用流消息协议——UMS UMS是Wormhole定义的流消息协议规范UMS试图抽象统一所有结构化消息UMS自身携带结构化数据Schema信息，方便数据处理UMS支持每一个消息中存在一份Schema信息及多条数据信息，这样，在存在多条数据时可以降低数据大小，提高处理效率说明： protocol-type目前支持data_increment_data（增量数据）和data_initial_data（初始化全量数据）schema-namespace指定数据对应的namespaceschema-fields描述每个字段的名称、类型、是否可空。ums_id_代表记录id，要求保证递增；ums_op_代表数据操作（i：插入；u：更新；d：删除）；ums_ts_代表数据更新时间payload-tuple指一条记录的内容，与schema-fields一一对应注：在Wormhole_v0.4.0版本后，应社区需求，支持用户自定义半结构化JSON格式 2）统一数据计算逻辑管道——Flow Flow是Wormhole抽象的流式处理逻辑管道Flow由Source Namespace、Sink Namespace和处理逻辑构成Flow支持UMS和自定义JSON两种消息协议Flow支持Event和Revision两种Sink写入模式Flow统一计算逻辑标准（SQL/UDF/接口扩展） （Flow） 说明：上图中蓝色框和箭头组成了一个Flow，首先从TopicA中读取Namespace1 (SourceNamespace)的数据，数据协议为UMS或者自定义JSON，然后处理用户配置好的数据处理逻辑，输出到Namespace2 (SinkNameSpace)对应的数据系统中，写入支持insertOnly和幂等（对同key且不同状态的数据保证最终一致性）。 作为一个实时大数据流式处理平台，Wormhole的设计目标和设计规范最终都是为流上处理数据而服务。本篇为Wormhole的具体功能做铺垫，下篇系列文章我们将为大家介绍Wormhole的具体功能。 作者：赵平 ...

国内的前端行业，是一个群星璀璨，同时又有些纷纷扰扰的圈子。很多初出茅庐的年轻人怀着改变世界的梦想，谁也不服谁。不过，有一些为前端领域做出贡献的拓荒者几乎受到所有人的尊敬，玉伯就是这些拓荒者中的一员。 如今，他已经是蚂蚁金服研究员，带领着体验技术部，打造出 Ant Design、AntV、Eggjs 等广受欢迎的开源项目，他所在的团队也成为国内前端开发者向往的地方。 在同事眼中，玉伯是一个严谨的人，同时保持着对生活的热爱，他曾以 lifesinger 为笔名写名为“岁月如歌”的博客、参与 GitHub 上的开源社区，到现在也经常在知乎上分享自己的知识和见解。 从中科院到支付宝时间转回到 2006 年，当时在中科院物理所进行硕博连读的玉伯对前途产生了迷茫，是就这样继续深造，将来投身学术界，还是出来干一番事业？ 当时，腾讯的 QQ 已经开始有所起色，在年轻人之间开始风靡，淘宝网已经成为中国最受欢迎的线上购物网站，互联网正风起云涌。这时，玉伯得知中科院软件所正在找人，一番思考之后，玉伯毅然放弃学业投身到软件行业。由于他当时年龄小，在软件所工作期间，经常闹出被误认为是学生的笑话。 中科院的生活单纯但缺乏激情，2008 年，玉伯终于离开了象牙塔，南下杭州，加入了当时正在招兵买马的淘宝 UED。虽然并非科班出身，但玉伯从 2002 年起就已经开始接触前端开发，从此与前端结下了不解之缘。 加入淘宝 UED 后，他与承玉等人一起研发了 Kissy，当时淘宝前台业务的标准前端技术栈，并将之开源，在 GitHub 上，Kissy 一度是阿里系开源项目 Star 数最多的项目。 在淘宝期间，玉伯还发起了 Sea.js，一个开源的 JavaScript 模块加载框架，它契合了前端工程化的演进趋势，也是现代大中型前端项目的基础。 2012 年，玉伯加入支付宝前端开发部，负责基础技术组。第二年，他遇到了职业生涯的另一个重大选择：阿里宣布“ALL IN 无线”，支付宝前端解体，所有人都面临选择，要么转岗去做移动端开发，要么留下来做中后台的前端开发。玉伯选择留了下来。 虽然从事后来看，无论是走的还是留的，结果都挺好的，但当时对于玉伯是一个痛苦的时刻，甚至对前端的价值产生了怀疑，他在《阿里前端的困局与突围》中写道： 一个事实：把国内大部分公司的 UX 部门解散掉，也不会太影响产品的体验。在国内，UX 主要还是起到美工的作用，虽然我不想承认。前端依旧是美工，而且仅仅是实现工。 在阿里，我们不得不承认一个事实：前端的确有价值，但放在全局来看，前端产生的价值并非核心价值。 在阿里，虽然前端的工作已经不可或缺，但对大公司而言，不可或缺的岗位多了去呢，不可或缺不代表有核心价值，我就不说了。不过好在，他很快振作起来，从中后台业务中找到了前端的价值。 “后来我们发现中后台业务也是有很多事情可以去做的，无论是业务还是技术都值得深挖，只是以前前端只关注 C 端业务，但其实 To B 的业务对前端来说是一片蓝海。”玉伯说。 玉伯发现中后台的业务量其实非常大，如果没有一套系统的规范来应对，研发效率和产品体验都将面临挑战。 在这样的背景下，前端技术部改名为体验技术部，玉伯和他的小伙伴们踏上了新的征程。 冰山之下的体验意识到中后台方面前端体验的缺失，玉伯开始带领团队做这方面的工作，他还专门招募了设计师团队，和前端工程师一起工作，开始在体验方面深挖。 设计师的加入让前端团队发生了巨大变化，也让玉伯开始思考体验的更深层含义，他在《我们是如何从前端技术进化到体验科技的》一文中表示： 前端技术再牛，都很难直接解决产品层的用户体验。对中后台产品来说，设计的价值也远远不止于让产品的颜值提升，设计的更多价值，在于深入到产品的业务逻辑里去，去帮助业务梳理产品信息架构与任务流程。用户体验是一个非常综合的事，需要各种专业人士在同一个产品上聚焦发力，一起共同努力才能真正提升产品体验。他还引用乔布斯的话说：设计不止于好看，更关乎好用。 为了让前端工程师和设计师更好的协作，玉伯说，团队曾经开展过一个活动：任何设计师的要求都是合理的，只要设计师提出的要求都尽可能的去实现，除非技术上的确实现不了。这个活动让设计师感觉到前端工程师的尊重，增进了双方的互相了解。而且前端工程师和设计师都是视觉型动物，都关注人机交互的细节，所以相处下来很融洽。 2015 年，体验技术部推出了 Ant Design，它有别于 UI 组件库，是一种全新的设计系统，随着 Ant Design 不断的证明自己，它受到了阿里内外的广泛赞誉，也在一定程度上引领了国内业界关注中后台体验的风潮。 ...

我们组织了一个开源互助平台，方便开源组织和大 V 互相认识，互相帮助，整合资源。请回复这个帖子并注明组织/个人信息来申请加入。请回复这个帖子来推荐希望翻译的内容。如果大家遇到了做得不错的教程或翻译项目，也可以推荐给我们。我们会联系项目的维护者，一起把它变得更好。我们的公众号等平台接受大家的投稿，请将文章链接发到这个帖子来投稿。为了能够将开源事业做大做强，ApacheCN 需要与公益基金会（IT、教育类）合作，欢迎大家提供帮助。如果你不希望再收到我们的邮件，请直接拉黑我们，不要浪费彼此的时间，谢谢合作。如果大家有适合我们的增长策略，包括你想尝试但是怕被骂的策略，可以交给我们来做实验。我们将使用激进的增长策略，尽可能让更多人了解我们。CS224n 自然语言处理（笔记整理）参与方式：https://github.com/apachecn/s... 整体进度：https://github.com/apachecn/s... 项目仓库：https://github.com/apachecn/s... 认领：12/20，整理：0/20 章节贡献者进度Lecture 1@cx123cx456 Lecture 2@AllenZYJ Lecture 3@cx123cx456 Lecture 4@ZSIRS Lecture 5@ZSIRS Lecture 6@ZSIRS Lecture 7@neolei Lecture 8@Qichao-Ge Lecture 9@NewDreamstyle192 Lecture 10@enningxie Lecture 11 Lecture 12 Lecture 13 Lecture 14 Lecture 15 Lecture 16 Lecture 17@pingjing233 Lecture 18 Lecture 19 Lecture 20@Willianan 短篇集（校对）参与方式：https://github.com/apachecn/m... 整体进度：https://github.com/apachecn/m... 项目仓库：https://github.com/apachecn/m... 关于卷积神经网络：认领：2/12，校对：2/12 章节贡献者进度关于卷积神经网络--1@daewis100%2.1.1-2.1.3@daewis100%2.1.4-2.1.6 2.2.1 2.2.2-2.2.3 2.3-2.4 3.1 3.2 3.3 3.4-3.5 4.1 4.2 写给不耐烦程序员的 JavaScript（校对）参与方式：https://github.com/apachecn/i... ...

SOFAStack Scalable Open Financial  Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。SOFALookout 是蚂蚁金服在 SOFAStack 体系内研发开源的一款解决系统的度量和监控问题的轻量级中间件服务。本文给大家介绍下 SOFALookout 服务器端主要提供的特性以及使用方式。SOFALookout：https://github.com/sofastack/sofa-lookout 前言容器，K8S，微服务，Mesh 以及 Serverless 这些新技术方向正在根本的变革我们运行软件的方式。我们构建的系统更加分布式化，另外由于容器，系统的生命周期更加短，变得易逝。针对这些变化，SOFALookout 希望提供一套轻量级解决方案。之前 SOFALookout 已经开源客户端的能力。今天，SOFALookout 服务器端 Metrics 部分的代码终于正式开源啦！本文给大家介绍下 SOFALookout 服务器端的主要特性以及使用方法。 什么是 SOFALookoutSOFALookout 是蚂蚁金服开源的一款解决系统的度量和监控问题的轻量级中间件服务。它提供的服务包括：Metrics 的埋点、收集、加工、存储与查询等。该开源项目包括了两个独立部分，分别是客户端与服务器端服务。 SOFALookout 目标是打造一套轻量级 Observability 实时工具平台，帮助用户解决基础设施、应用和服务等的监控和分析的问题。SOFALookout（目前已开源部分） 是一个利用多维度的 metrics 对目标系统进行度量和监控的项目。SOFALookout 的多维度 metrics 参考 Metrics2.0 标准。 SOFALookout ：https://github.com/sofastack/sofa-lookoutSOFALookout 安装文档：https://www.sofastack.tech/sofa-lookout/docs/quickstart-metrics-server  SOFALookout 服务器端的主要特性: 适配社区主要 Metrics 数据源协议写入（比如: Prometheus，Metricbeat 等）；数据的存储支持扩展，暂时开源版默认支持 Elasticsearch， 并且透明和自动化了相关运维操作；遵循 Prometheus 查询 API 的标准以及支持 PromQL，并进行了适当改进；自带数据查询的控制台，并支持 Grafana 进行数据可视化；使用简单，支持单一进程运行整个服务器端模块。随着 SOFALookout （metrics）服务器端代码开源，metrics 数据的处理已经形成闭环。后续我们将会进一步开源 Trace 和 Event 相关的服务能力，敬请期待。 SOFALookout 项目结构服务器端代码分别包括两部分：Gateway 模块和 Server 模块。如下图所示（展示了 SOFALookout 源码项目的模块概要结构） ├── boot├── client├── gateway└── server项目中的 boot 模块作用是方便集成和运行服务端的模块，既可以单独运行 Gateway 和 Server 的服务，也可以借助 SOFAArk 完成（Gateway 和 Server）的 All in One 的合并为单一进程运行。 ...

引言最近宜信开源微服务任务调度平台SIA-TASK，SIA-TASK属于分布式的任务调度平台，使用起来简单方便，非常容易入手，部署搭建好SIA-TASK任务调度平台之后，编写TASK后配置JOB进行调度，进而实现整个调度流程。本文新建了JOB示例，该JOB关联了前后级联的两个TASK，TASKONE(前置TASK)和TASKTWO(后置TASK)，主要阐述一个JOB怎样关联配置两个级联TASK，以及该JOB是如何通过SIA-TASK实现任务调度，最终实现对两个TASK执行器的调用。 拓展阅读：宜信开源|宜信开源微服务任务调度平台SIA—TASK宜信开源|分布式任务调度平台SIA-TASK的架构设计与运行流程 首先，根据部署文档来搭建任务调度平台。源码地址：https://github.com/siaorg/sia... 官方文档：https://github.com/siaorg/sia... 任务调度平台主要由任务编排中心、任务调度中心以及ZK和DB等第三方服务构成，搭建SIA-TASK任务调度平台需要的主要工作包括： 1.MySQL的搭建及根据建表语句建表 2.zookeeper安装 3.SIA-TASK前端项目打包及部署 4.任务编排中心(sia-task-config)部署 5.任务调度中心(sia-task-scheduler)部署 从github上clone代码仓库并下载源码后，可根据SIA-TASK部署指南，搭建SIA-TASK任务调度平台并启动，详见SIA-TASK部署指南 搭建好SIA-TASK任务调度平台后，下一步就是TASK执行器实例的编写啦。 其次，根据开发文档来编写TASK执行器实例并启动。根据SIA-TASK开发指南，编写了两个TASK示例，TASKONE(前置TASK)和TASKTWO(后置TASK)，具体开发规则见SIA-TASK开发指南，TASK示例关键配置即代码在下文有详细展示与介绍。 该示例为springboot项目，并且需要通过POM文件引入SIA-TASK的执行器关键依赖包sia-task-hunter来实现task执行器的自动抓取，首先需要将SIA-TASK源码中的sia-task-hunter包用mvn install命令打包为jar包安装至本地仓库，SIA-TASK源码中的sia-task-hunter包如下图示： 然后就可以进行示例的编写，示例主要包括以下几部分： 配置POM文件关键依赖 <!-- 此处添加个性化依赖(sia-task-hunter) --> <dependency> <groupId>com.sia</groupId> <artifactId>sia-task-hunter</artifactId> <version>1.0.0</version> </dependency>配置文件主要配置项 # 项目名称（必须） spring.application.name: onlinetask-demo # 应用端口号（必须） server.port: 10086 # zookeeper地址（必须） zooKeeperHosts: *.*.*.*:2181,*.*.*.*:2181,*.*.*.*:2181 # 是否开启 AOP 切面功能（默认为true） spring.aop.auto: true # 是否开启 @OnlineTask 串行控制（如果使用则必须开启AOP功能）（默认为true）（可选） spring.onlinetask.serial: true编写TASK执行器主要代码@Controllerpublic class OpenTestController { @OnlineTask(description = "success,无入参",enableSerial=true) @RequestMapping(value = "/success-noparam", method = { RequestMethod.POST }, produces = "application/json;charset=UTF-8") @CrossOrigin(methods = { RequestMethod.POST }, origins = "*") @ResponseBody public String taskOne() { Map<String, String> info = new HashMap<String, String>(); info.put("result", "success-noparam"); info.put("status", "success"); System.out.println("调用taskOne任务成功"); return JSONHelper.toString(info); } @OnlineTask(description = "success,有入参",enableSerial=true) @RequestMapping(value = "/success-param", method = { RequestMethod.POST }, produces = "application/json;charset=UTF-8") @CrossOrigin(methods = { RequestMethod.POST }, origins = "*") @ResponseBody public String taskTwo(@RequestBody String json) { Map<String, String> info = new HashMap<String, String>(); info.put("result", "success-param"+"入参是："+json); info.put("status", "success"); System.out.println("调用taskTwo任务成功"); return JSONHelper.toString(info); }}当编写完TASK执行器实例后，启动该执行器所在进程启动日志如下图： ...

在开始之前　抛出一个问题开源软件和商业软件有冲突吗？ 开源协议如何选择一张图介绍如何选择最流行的六种开源许可证 这是乌克兰程序员Paul Bagwell，画的一张分析图，介绍最流行的六种开源许可证----GPL、BSD、MIT、Mozilla、Apache和LGPL。 常用开源协议介绍开源在今天的软件业已经很普遍，但开源是否意味着使用者可以对开源后的代码为所欲为呢？答案是否定的。开源运动同样有自己的游戏规则和道德准则。不遵行这些规则不但损害开源运动的健康发展，也会对违规者造成名誉和市场上的损失，更可能陷入法律纠纷和赔偿。 现今存在的开源协议很多，而经过Open Source Initiative组织通过批准的开源协议目前有58种。我们在常见的开源协议如BSD, GPL, LGPL,MIT等都是OSI批准的协议。如果要开源自己的代码，最好也是选择这些被批准的开源协议。 这里我们来看四种最常用的开源协议及它们的适用范围，供那些准备开源或者使用开源产品的开发人员/厂家参考。 BSD开源协议BSD开源协议是一个给于使用者很大自由的协议。基本上使用者可以”为所欲为”,可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。 但“为所欲为”的前提当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件： 1． 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。 2． 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。 3． 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。 BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。 Apache Licence 2.0Apache Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改，再发布（作为开源或商业软件）。需要满足的条件也和BSD类似： 1． 需要给代码的用户一份Apache Licence 2． 如果你修改了代码，需要再被修改的文件中说明。 3． 在延伸的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。 4． 如果再发布的产品中包含一个Notice文件，则在Notice文件中需要带有Apache Licence。你可以在Notice中增加自己的许可，但不可以表现为对Apache Licence构成更改。 Apache Licence也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布/销售。 GPL我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux，包括商业公司的linux和linux上各种各样的由个人，组织，以及商业软件公司开发的免费软件了。 GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用，修改后的代码或者衍生代码)GPL协议的产品，则该软件产品必须也采用GPL 协议，既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题，还可以享受免费的优势。 由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。 其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。 LGPLLGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。 LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。 但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。 GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。 P.S. 随手写写，是因为跟客户交谈的时候发现很多人其实对开源有完全错误的理解，特别是开源协议。很多人认为只要是开源，就意味着随便用，随便改都可以。 商业软件 vs. 免费软件 网友讨论dlee补充： 这些知识 Linux Fans 大多比较清楚，因为经常使用开源软件，每天下载源代码，编译、测试、安装是常事。这些问题在各个 Linux 论坛上也早已经是老生常谈，但是有些 Java Fans 以及大多数 M$ 平台的开发人员几乎一无所知。我在这里一般不会谈跟 Java 关系不大的内容。既然 Charlesxp 想谈谈，我也补充一下。 ...

上一讲中，我们深入探讨了区块链对一些基本问题的答案，包括对时间的答案、对空间的答案以及对能量的答案。在这一篇文章中，我们将从区块链作为基本工具的工具论方面切入。这个方面包括了它是怎样看待这个世界的：它使用了哪些工具，以及它使用了哪些方法？构造了哪些全新的博弈环境并形成了哪些新的博弈均衡态？这些方法也许和人们过去所知道的方法都不太一样，就像原始人无法理解一个现代白领的工作意义一样。这些玩法也是区块链的核心，需要人们去重新理解，积极参与的，并将从根本上重新塑造人与人之间，人与物质世界之间的关系。秘猿科技区块链小课堂第 9 期 （一）区块链是软件开源运动结出的果实接下来让我们来了解一下，在整个新的商业结构里面还有哪些玩法是大家不熟悉的。 区块链是软件开源运动所结出的果子。在以下这张图中左侧是软件开源，右侧是硬件开源。软件开源是从 1991 年的开源系统 Linux1.0 开始的。硬件开源也有很多。其中有一个叫做 RISC-V。在这里简单地介绍一下，因为这可能跟目前所说的内容有关系。RISC-V 是 CPU 的指令集。 1.个人电脑的指令集在个人电脑时代，只存在一个指令集。这个指令集叫做 x86。这个指令集是英特尔还有 AMD 公司正在使用的指令集。然而这个指令集是闭源的。并且这个指令集非常复杂。现如今它包括了几十万条的指令。现今个人电脑的英特尔制造的 CPU 用的指令集就是 x86 指令集。 这种指令集有两个特点。第一，它的存在是闭源的。换言之，只有特定公司懂得如何编译这种指令集。第二，这个指令集非常的复杂。其中有几十万条指令。这么多指令是很难进行修改的。将这个指令集开源，其他人也看不懂；能看懂也不敢改，一改很可能就崩了。非专业人员很难对这些指令进行编译。这种商业模式给英特尔这些核心的芯片厂商带来了巨额的垄断利润。 2．手机端的指令集还有一个指令集。它是手机芯片的 ARM 指令集。编译这个指令集的公司是一家英国公司。这个指令集是有开放许可的。授权费用大概在 1000 万到 2000 万美元之间。有这个指令集的存在，谷歌开源的安卓系统才会大规模应用。安卓就是手机操作系统软件的开源。ARM 并不是开源，但是它是公开许可使用的。所以在国内可以看到众多厂商，只要它是一个大规模的公司，这些厂商就可以制做自己的手机，比如步步高的 OPPO 和 VIVO。还有很多家电厂商也可以做手机，比如 TCL。这是一种商业模式。 这也是中国现在手机厂商能够通过自己努力去占领印度以及非洲市场的原因。印度人用的手机和非洲很多国家的人用的手机都是中国制造，但是手机的品牌大多数人在国内并没有没听说过。这种手机并不在中国售卖。它们不是针对中国人设计的产品。它们的设计理念是超长待机。超长待机是什么概念？这些手机充一次电可以用半个月。因为有些非洲国家的人时隔半个月才能找到可以充电的地方。所以这些手机不是为中国人设计的。但是人们会发现这个市场比原来宽松了许多。 3．物联网时代的指令集说完个人电脑和手机的指令集，我们现在来谈谈物联网时代的指令集。我们将RISC-V 称之为物联网时代的指令集。这是一个什么样的指令集呢？这个指令集是 2016 年加州伯克利大学专门研究指令集的教授做的。这个指令集的指令十分简略，基本指令控制在一百条以内。这个教授说：根据他多年对指令集的研究，这一百条以内的指令可以搭建出其它所有的复杂的指令。而且这个指令集是开源的。不知道大家对 IC 行业有没有了解。现在已经有很多基于 RISC-V 的芯片在流片了。也存在很多大的芯片生产设计厂商提出会支持 RISC-V。 RISC-V 是专门为物联网设计的。它的指令集会达到 32 位甚至更小的 16 位，并拥有更低的耗能。在不远的将来，人们就会看到，过去的昂贵的嵌入式芯片很快就会被基于 RISC-V 的芯片全部替代。 这个改变是 2016 年才开始的，到现在为止也不到三年时间。因此这会是一个重大的机会。 这个就是开源的玩法，我们看到大量的软硬件产品在进行开源，包括很多大厂的产品。以上提到的软硬件对程序员或者从事 IC 行业的人来说应该更为熟悉。这些软硬件都是他们日常在使用的。在这个过程中也许中间出现了很多误解，开源到底是什么意思？首先代码开源运动不代表着免费。代码开源运动被称为自由代码运动。任何人都可以使用这些代码，但是不代表这些代码是免费的。 （二）区块链和开源运动的关系1.区块链应该是开源的那么区块链和开源运动是什么关系呢？有这样一个说法：没有开源就没有区块链。原因是区块链创造的信任是基于代码产生的。这里存在误解。这个误解是就很多国内的公司不会宣传自己的做的区块链是开源的。很多人会问如果做的是区块链，为什么不开源？这些公司不敢对区块链进行开源的原因，我不敢妄自揣测。但是如果所做的区块链不是开源的，其他人就不能看到对应的代码。不能看到代码就不能证明这个是区块链还是一个 TPS 很高的中心化系统。因此不开源的区块链技术是无法在技术上实现区块链的增信的，你还只是在信任这家区块链公司而已。 2.对区块链的信任建立在它代码之上那么最早比特币的信用又是怎样一点点搭建起来的呢？原因并不是中本聪这个人。是因为中本聪长得帅还是因为中本聪有钱呢？其实都不是。当然也不是因为比特币的白皮书。很多人非常看重白皮书。白皮书其实没那么重要，白皮书就是一个 vision，它是一个编写出的梦想。 对比特币的信任来自它的代码。这种信任是一步步建立的。到后来才有很多人开始觉得比特币可以信任。在这之后比特币才扩展成了一个网络。最后网络成型了，大家都愿意持续地在这个网络和网络的交易逻辑上进行投入。这种信任是基于代码增长起来的。 比特币的代码在对量进行控制。代码也在对账户进行控制。代码允许用户自己对量进行控制并且对账户进行控制。这种信任是基于代码的。因此我想说黄皮书比白皮书重要无限倍。 3.区块链白皮书、详细设计文档与开源代码在 ICO 风潮出现之后，大家都会去看白皮书。这是完全错误的方向。正确的做法是去看它详细设计文档和代码写的如何。详细设计文档是什么呢？以区块链详细设计文档的著名代表，Garvin Wood 撰写的以太坊黄皮书为例，它的细节丰富完备，定义清晰严格，逻辑自洽，根据这个黄皮书的内容，以太坊白皮书的内容在设计上具有很强的说服力了，才会有人进行投资和支持。只有白皮书是无法证伪所提出来的愿景是可以在工程上和博弈关系上实现的。另一方面要看代码，代码已经基本完成并且已经开源，程序员们才能通过去 review 以及测试这些代码，在觉得代码是可行的，才会进行投资。这里要补充强调一点，并不是一个项目有了详细设计文档和开源代码，就一定是靠谱的项目，但是相对于一个没有提供任何可以证伪的材料的项目而言，有详细设计文档和开源代码的项目至少是走在一个有诚意的、科学的道路上。 ...

一、分布式任务调度的背景无论是互联网应用或者企业级应用，都充斥着大量的批处理任务。我们常常需要一些任务调度系统来帮助解决问题。随着微服务化架构的逐步演进，单体架构逐渐演变为分布式、微服务架构。在此背景下，很多原先的任务调度平台已经不能满足业务系统的需求，于是出现了一些基于分布式的任务调度平台。 1.1 分布式任务调度的演进在实际业务开发过程中，很多时候我们无可避免地需要使用一些定时任务来解决问题。通常我们会有多种解决方案：使用 Crontab 或 SpringCron (当然这种情况可能机器很少而且任务简单又不是很多的情况下)。然而，当应用复杂度升高、定时任务数量增多且任务之间产生依赖关系时，Crontab 进行定时任务的管理配置就会非常混乱，严重影响工作效率。这时就会产生一系列问题： 任务管理混乱，生命周期无法统一协调管理；任务之间如果存在依赖关系，难以编排。随着互联网的发展，分布式服务架构势越来越流行。相应的也需要一个分布式任务调度系统来管理分布式架构中的定时任务。 1.2 分布式任务调度架构 当垂直应用越来越多，应用之间交互也会越来越复杂，通常我们采用分布式或者微服务架构，将核心业务抽取出来，形成单独的服务。一个独立的微服务群体逐渐形成稳定的服务中心，使得业务应用能更快地响应多变的市场需求。 此时，用于提高业务复用及整合的分布式服务框架成为关键。同时，由于服务独立，一般能做到定时任务独立的情况，任务的更改对于整体系统的影响小之又小。通常我们会采用任务与调度分离的方式（如上图所示），任务的执行逻辑无需关注调度与编排，同时可以保证执行器和调度的高可用，易于开发和维护。 1.3 分布式任务调度优势在分布式服务架构的基础上，由于独立业务的数量可能很多，此时如果定时任务单独在该服务中实现，很可能会出现难以管理的情况，且避免不了由于定时任务的更改而导致的业务重启。因此，一个独立的分布式任务调度系统是很必要的，可以用来全局统筹管理所有的定时任务。同时，将任务的配置单独抽离出来，作为该分布式任务调度系统的功能，就能做到定时任务的更改不影响任何业务，也不影响整个系统： 通过调度与任务分离的方式进行管理，大大降低了开发和维护成本；分布式部署，保证了系统的高可用性、伸缩性、负载均衡，提高了容错性；可以通过控制台部署和管理定时任务，方便灵活高效；任务都可以持久化到数据库，避免了宕机和数据丢失带来的隐患，同时有完善的任务失败重做机制和详细的任务跟踪及告警策略。二、分布式任务调度技术选型2.1 分布式任务调度考虑因素 任务编排：多个业务之间的定时任务存在流程次序。任务分片：对于一个大型任务，需要分片并行执行。跨平台：除了使用 Java 技术栈（SpringBoot、Spring等）的项目之外，还有使用其他语言的应用。无侵入：业务不希望与调度高耦合，只关注业务的执行逻辑。故障转移：任务执行过程中遇到问题有补偿措施，减少人工介入。高可用：调度系统自身必须保证高可用。实时监控：实时获取任务的执行状态。可视化：任务调度的操作提供可视化页面，方便使用。动态编辑：业务的任务时钟参数可能变动，不希望停机部署。2.2 SIA-TASK与其它分布式任务调度技术比较SIA是宜信公司基础开发平台Simple is Awesome的简称，SIA-TASK（微服务任务调度平台）是其中的一项重要产品，SIA-TASK契合当前微服务架构模式，具有跨平台、可编排、高可用、无侵入、一致性、异步并行、动态扩展、实时监控等特点。 开源地址：https://github.com/siaorg/sia-task 我们先对比市场上主流的开源分布式任务调度框架，分析其优缺点，然后再介绍我们的技术选型。 Quartz: Quartz 是 OpenSymphony 开源组织在任务调度领域的一个开源项目，完全基于 Java 实现。该项目于 2009 年被 Terracotta 收购，目前是 Terracotta 旗下的一个项目。相比于 JDK 或 Spring 提供的定时任务，Quartz 对单个任务的控制基本做到了极致，以其强大功能和应用灵活性，在企业应用中发挥了巨大的作用。然而 Quartz 并不支持任务的编排（任务之间有依赖），而且不支持任务分片。TBSchedule: TBSchedule 是一个支持分布式的调度框架，能让一种批量任务或者不断变化的任务，被动态地分配到多个主机的 JVM 中，不同的线程组中并行执行。基于 ZooKeeper 的纯 Java 实现，由 Alibaba 开源。TBSchedule 侧重于任务的分发，支持任务分片，但是没有任务编排，也不是跨平台的。Elastic-Job: Elastic-Job 是当当开源的一个分布式调度解决方案，由两个相互独立的子项目Elastic-Job-Lite 和 Elastic-Job-Cloud 组成。Elastic-Job 支持任务分片（作业分片一致性），但是没有任务编排，也不是跨平台的。Saturn: Saturn 是唯品会开源的分布式，高可用的调度服务。Saturn 在 Elastic-Job 做二次开发，支持监控、任务分片、跨平台，但是没有任务编排。Antares: Antares 是基于 Quartz 的分布式调度，支持分片、支持树形任务依赖，但不是跨平台的。Uncode-Schedule: Uncode-Schedule 是基于 Zookeeper 的分布式任务调度组件。支持所有任务在集群中不重复、不遗漏的执行。支持动态添加和删除任务。但是不支持任务分片，也没有任务编排，还不是跨平台的。XXL-JOB: XXL-JOB 是一个轻量级分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。XXL-JOB 支持分片，简单支持任务依赖，支持子任务依赖，不是跨平台的。下面我们简单对比下 SIA-TASK 与这些任务调度框架： ...

背景应用微服务化场景下，随着服务个数的增加，服务之间的相互调用变得更加复杂，服务治理需求愈加突出，其中服务流量控制是服务治理中的重要一环。 当前常用的流量控制方案主要有基于Spring Cloud的Hystrix和阿里开源的Sentinel应用流量控制降级方案。客观而言，两个方案都是侵入式的，要求用户在应用中引入相关包，编写相关逻辑。 UAVStack作为一套智能化服务技术栈，其服务治理（UAV.ServiceGovern）模块提供了基于画像的服务注册与发现、服务访问授权及服务流量控制能力。 本文主要介绍UAVStack的无侵入式服务流量限制及降级方案。安装UAV后，通过页面配置即可用实现常用的QPS限流等。 一、限流模型 图1限流模型 UAV服务治理流量控制采用上图所示的漏斗+能力池限流模型。将应用根据UAV画像抽象出三层，分别是应用层（应用实例层）、服务组件层和URL层。每一层均可以添加多个限流策略，多个限流策略以“且”的关系存在。请求呈漏斗状依次进入URL层限流、服务组件层限流、应用层限流，只有通过三层限流后才能进入应用。 应用层（应用实例层）：应用层代表当前应用实例整体，应用层限流即限制进入当前应用的总流量。应用层限流流量为服务组件层和URL层流量上限；服务组件层：服务组件层是应用下所有服务组件的集合，包含一个或多个服务组件。可以针对每个服务组件配置不同的限流和降级策略，每个服务组件包含0个或多个URL；URL层：URL层包含所有服务URL。URL层限流即限制进入具体URL的流量。流量控制的目标不是仅仅限制QPS，还要限制对系统资源的使用。服务能力池描述当前应用或组件对外提供的服务能力的上限，该上限为池的最大容量；由于不同的请求消耗的系统资源不一样，因此每种类型的请求将会被赋予不同的权重值。重的请求消耗更多系统资源，将被赋予更大的权重值，而轻的请求赋予较小的权重值。每个请求都会根据权重值消耗服务能力池中的能力，重的请求比轻的请求消耗得服务能力多。无法从服务能力池中获取足够的服务能力时，便会触发降级策略。 二、关键技术2.1 MOF中间件劫持MOF(MonitorFramework)中间件劫持为UAV服务治理中流量控制提供基础支撑。主要提供以下几方面的支撑： 请求捕获：捕获所有进入应用容器的请求，并将请求转入限流模型处理流程，实现流量控制和请求降级；流量控制策略配置：基于MOF提供的基础能力实现流量控制策略配置、当前限流状态查询/开启/关闭等热控制。2.2 限流器和降级策略UAV服务治理默认支持两种限流器：时间段计数限流器和基于令牌桶算法的服务能力限流器。 时间段计数限流器通过原子量累计时间段内请求个数。当请求个数超过限制总数时，执行降级策略。默认的降级策略是终止请求处理流程，返回TOO_MANY_REQUEST。UAV服务治理支持开发和配置自定义的降级策略。 基于令牌桶算法的服务能力限流器会随着时间变化按恒定时间间隔(1/QPS，如果QPS=100,则间隔是10ms)向服务能力池中里补充，直至将能力池填满。出现新请求时，会根据当前请求权重值N拿走N个Token；如果没有足够的Token可取，则会阻塞或拒绝请求，从而执行拒绝策略。基于令牌桶算法的服务能力限流器也支持开发和配置自定义的降级策略。 UAV服务治理不仅支持自定义降级策略，也支持自定义限流器，满足不同用户的不同需求。 三、功能展示3.1 限流策略配置树页面根据应用画像以配置树形将应用展示为三层：应用实例层、服务组件层、URL组件层。如图2所示，应用实例层节点代表当前应用实例（仅有一个）；服务组件节点代表当前应用下的某一具体服务组件，如RS服务组件，每个服务组件下可能包含0个或多个URL节点；一个URL节点代表应用对外提供的服务的具体URL。 流量控制策略可以配置在三层中的任意节点上。配置在应用实例层节点可以限制进入整个应用的流量；配置在服务组件节点上可以控制当前服务组件下所有URL的流量；配置在URL节点上可以限制访问当前URL的流量。 图2 应用配置树 3.2 策略配置及策略下发策略配置中主要配置限流器、限流器参数、降级策略及降级策略参数。默认限流器是基于令牌桶算法的服务能力限流器，URL节点需要配置限流阈值和当前节点的请求权重值。请求超过阈值时，默认降级策略会返回TOO_MANY_REQUEST。 图3 策略配置 配置策略完成，通过策略下发按钮将策略下发至目标应用，同时展示当前实时限流状态。 图4 策略下发结果状态展示 3.3 限流效果及性能展示图5为极简应用（接收到请求后直接返回）场景下的测试结果，包括在压力不断增强的情况下应用原生吞吐量（红线）、安装UAV不启用限流的吞吐量（黑线）、安装UAV限流900QPS时应用接收到的请求量（限流900整体，蓝线）、限流900QPS时正常处理的请求量（橙线，限流900正常请求）及限流900QPS时拒绝的请求量（绿线，限流900限流请求）。 图5 应用吞吐量测试 从图5中可以看出，对比原生和安装UAV无限流情况，UAV限流对应用的吞吐量影响比较小，基本可以忽略不计。随着请求量的增加，进入应用的正常请求量（橙线）稳定在900左右，被限流的请求量随着整体请求量增加而增加，且与未被限流的请求量之和为整体请求量，表明UAV限流有效。另一方面，随着请求量的增加，在原生和无限流的情况下，应用吞吐量在1500左右达到上限；但在限流900QPS的情况下，应用请求量一直在增加，因为超出的请求被直接拒绝，没有进入应用中，从侧面体现了UAV限流对应用的保护能力。 图6为极简应用场景的测试结果，为应用在压力不断增强的情况下的平均响应时间。在原生和无限流情况下（红线和黑线），应用的平均响应时间随着压力增大而增加，最终在1300左右时大幅增加，说明应用的服务能力已经接近极限；在UAV限流900QPS的情况，正常请求（橙线）的平均响应时间即使超过1300达到2100时也基本保持稳定，被拒绝的请求的平均响应时间未见大幅变动，应用服务器的平均响应时间也基本保持稳定。UAV限流对应用实现了有效保护。 图6 应用平均响应时间测试 总结服务治理是微服务化场景下的一个重要问题。本文仅简单介绍UAV服务治理中服务端限流部分原理和功能展示。由于篇幅有限，暂不详细展开介绍。大家有兴趣可以继续关注UAVStack公众号或申请加入官方微信群，相信您一定会有所收获。 官方网站：https://uavorg.github.io/main/ 开源地址：https://github.com/uavorg UAVStack已在Github上开放源码，并提供了安装部署、架构说明和用户指南等双语文档，欢迎访问-给星-拉取~~~ 作者：曾礼 原文发布于：UAVStack智能运维

拓展阅读：宜信开源|详解PaaS平台LAIN的功能和架构 宜信开源|一个实例解析PaaS平台LAIN的9大杀手级功能 一、安装 LAIN 集群本节包含三种场景下安装LAIN集群 本地启动虚拟机安装LAIN集群，可供本地测试开发物理服务器/虚拟机安装LAIN集群云服务器安装LAIN集群三者都需要从 GitHub 获取已经发布的 LAIN 版本源代码:https://github.com/laincloud/... 下载源码后在目标机器上解压即可。 tar xf lain-VERSION.tar.gz1、本地安装LAIN集群1）环境依赖 Linux / MacOS能够连接到互联网VirtualBox 5.1.22 r115126 (Qt5.6.2)Vagrant 1.9.4最少 2G 剩余内存（如果需要拉起多个节点，最少 3G）2）初始化 启动并初始化第一个节点 cd lain-VERSIONvagrant up --provision启动耗时取决于 vagrant box 下载时间, 启动完成后 vagrant 会自动 执行bootstrap进行初始化, 初始化需要至少20分钟，取决于网络速度。 初始化过程为集群默认配置vip=192.168.77.201 如果出现以下错误： Vagrant was unable to mount VirtualBox shared folders. This is usuallybecause the filesystem "vboxsf" is not available. This filesystem ismade available via the VirtualBox Guest Additions and kernel module.Please verify that these guest additions are properly installed in theguest. This is not a bug in Vagrant and is usually caused by a faultyVagrant box. For context, the command attempted was:mount -t vboxsf -o uid=1000,gid=1000 vagrant /vagrantThe error output from the command was:/sbin/mount.vboxsf: mounting failed with the error: No such device这个错误是因为宿主机的 Virtual Box 的 Guest Additions 与 laincloud/centos-lain box 已安装的 Guest Additions 版本不一致引起的，导致无法创建 /vagrant 这个同步 目录。请修改工程根目录下的 Vagrantfile，禁止宿主机强行安装新版本的 Guest Additions， 即添加如下配置： ...

内容来源：宜信技术学院第2期技术沙龙-线上直播|宜信敏捷数据中台建设实践 分享嘉宾：宜信数据中台平台团队负责人 卢山巍 导读：宜信于2017年推出了一系列大数据开源工具，包括大家熟悉的DBus、Wormhole、Moonbox、Davinci等，在技术社区内得到了广泛关注和好评。这些工具是如何在宜信内部应用的？它们和宜信数据中台是怎样的关系？又是如何驱动各种日常数据业务场景的？本次分享对这些问题进行了回答，同时重点分享了宜信敏捷数据中台的设计、架构以及应用场景，提出一种敏捷数据中台的建设思路，以供参考和探讨。以下是本次分享的实录。 分享大纲： 一、导语 二、宜信数据中台顶层设计 三、从中间件工具到平台 四、典型案例分析 五、总结 六、Q&A 视频回放地址：https://v.qq.com/x/page/r0874... PPT下载地址：https://pan.baidu.com/s/1jRum... 一、导语目前“中台”的概念很火，包括数据中台、AI中台、业务中台、技术中台等。宜信技术学院第一期技术沙龙，井玉欣博士分享了宜信的AI中台，本期技术沙龙，由我来为大家分享《宜信敏捷数据中台建设实践》。 为什么我们要在数据中台前加上“敏捷”呢？了解我们的朋友都知道我所在的团队是宜信敏捷大数据团队，我们倡导“敏捷平民化”，把敏捷思想融入到系统建设中，并且研发了四个开源平台：DBus、Wormhole、Moonbox、Davinci。宜信的数据中台是由我们敏捷大数据团队基于四大开源平台开发建设的，因此我们将宜信的数据中台称之为“敏捷数据中台”。 本次分享分为三个部分： 宜信敏捷数据中台的顶层设计。数据中台是一个公司级的平台系统，所以不能只从技术层面去设计，还要考虑包括流程、标准化等在内的顶层设计。从中间件工具到平台介绍宜信是如何设计建设敏捷数据中台的。结合典型案例介绍宜信敏捷数据中台支持哪些数据方面的应用和实践。二、宜信敏捷数据中台的顶层设计2.1 特点和需求关于数据中台的建设，目前并没有一个标准的解决方案，也没有一个数据中台能适用于所有的公司，每个公司都应该结合自己的业务规模及数据需求现状来研发适合自己公司的数据中台。 在介绍宜信敏捷数据中台的顶层设计之前，我们先来了解其背景： 业务板块和业务条线众多。宜信的业务大体可分为四大板块：普惠金融板块、财富管理板块、资产管理板块、金融科技板块，拥有近百条业务线和产品线。技术选型众多。不同业务方有不同的数据需求，技术选型时依据这些客观需求及主观偏好，会选择不同的数据组件，包括 ：MySQL、Oracle、HBase、KUDU、Cassandra、Elasticsearch、MongoDB、Hive、Spark、Presto、Impala、Clickhouse等。数据需求多样。业务线多样，导致数据需求多样，包括：报表、可视化、服务、推送、迁移、同步、数据应用等。数据需求多变。为顺应互联网的快速变化，业务方的数据需求也是多变的，经常有周级产出数据需求和数据应用。数据管理考虑。要求数据元信息可查，数据定义和流程标准化，数据管理可控等。数据安全考虑。宜信作为一家同时拥有互联网属性和金融属性的公司，对数据安全和权限的要求很高，我们在数据安全方面做了很多工作，包括：多级数据安全策略、数据链路可追溯、敏感数据不可泄露等。数据权限考虑。在数据权限方面的工作包括：表级、列级、行级数据权限，组织架构、角色、权限策略自动化。数据成本考虑。包括集群成本、运维成本、人力成本、时间成本、风险成本等。2.2 定位关于数据中台的定位，每个公司都不太一样。有的公司业务比较专注，只有一条业务线，那它在建设数据中台的时候，可能需要一个垂直的平台，直达前线，更好地支持前线的运作。 前文提到宜信业务线很多，且在众多业务中没有一个主体业务，这就相当于所有业务线都是主体。基于这样的背景，我们需要一个平台化的数据中台，来支撑所有业务线的需求和运作。 图1 定位 如上图所示，绿色的部分是宜信敏捷数据中台，我们称之为“ADX数据中台平台”，“A”即“Agile（敏捷）”，之所以称为“平台”，是因为我们希望将其打造成一个服务于全业务线的平台系统，助力业务发展。 敏捷数据中台处于中间位置，最底下是各种数据集群，最上端是各个业务领域数据团队。数据中台通过整合处理数据集群的数据，为业务领域数据团队提供自助化、实时化、统一化、服务化、管理化、可溯化的数据服务。 右边三个蓝色的板块分别是数据管理委员会、数据运维团队和数据安全团队。前文提到宜信对数据安全的要求非常高，所以设置了专门的数据安全团队来规划公司数据安全的流程和策略；数据管理委员会负责数据的标准化、流程化，补齐技术型驱动的数据中台的推动效率，保证有效沉淀和呈现数据资产。 我们对宜信敏捷数据中台的定位是：从数据技术和计算能力复用，到数据资产和数据服务复用，敏捷数据中台会以更大价值带宽，快、准、精让数据直接赋能业务。 2.3 价值宜信敏捷数据中台的价值集中表现为三个方面：快、准、省。 图2 价值 存在的问题敏捷数据中台之“快”定制化需求造成重复开发平台化，透明封装复用技术组件内包实施团队需排期自助化，简单配置，月=>天T+1延时满足不了实时及精细化运营实时化，驱动业务增长，天=>分存在的问题敏捷数据中台之“准”数据存储各异，取数方式各异，清洗逻辑各异统一化，统一数据湖归集和出口数据孤岛未打通整合管理化，元数据、数据地图、血缘需求驱动实施，无法沉淀数据资产资产化，模型管理让数据可信赖，标准化模型加工促使数据资产沉淀存在的问题敏捷数据中台之“省”时间成本，需求排期和重复开发自助化，节省时间就是节省成本人力成本，重复开发和缺少复用平台化，成熟技术组件高复用度硬件成本，集群资源滥用造成浪费精细化，集群资源可估可查可量化2.4 模块架构维度 图3 模块架构维度 如图所示，宜信敏捷数据中台的建设也是基于“小前台，大中台”的共识。整个中间部分都属于敏捷数据中台包含的内容，左边绿色部分是基于数据维度来看整个中台，右边蓝色部分则是基于平台维度来看中台。 数据维度。各种内部数据、外部数据先归集到数据源层，再以统一化、实时化、标准化、安全化等方式存储起来形成数据湖层，数据湖对这些原始数据进行处理和体系化归类，转化为数据资产；数据资产层包括数仓体系、指标体系、标签体系、特征体系、主数据等；最后将沉淀的这些可复用的数据资产提供给数据应用层，供BI、AI、数据产品应用。平台维度。每个蓝色的方框都代表一个技术模块，整个宜信敏捷数据中台就是由这些技术模块组合而成。其中DataHub数据枢纽，可以帮助用户完成自助数据申请、发布、脱敏、清洗和服务等；DataWorks数据工坊，可以对数据进行自助查询、作业、可视化等处理；还有DataStar数据模型、DataTag数据标签、DataMgt 数据管理、ADXMgt 中台管理等。值得一提的是，这些模块都不是从0开发的，而是基于我们已有的开源工具。首先，基于成熟的中间件工具来进行开发，可以节约开发的时间和成本；其次，开源工具成为引擎，可以共同合力支撑更大的一站式平台。 2.5 数据能力维度 图4 数据能力维度 将上述架构模块重新按照能力维度划分，可以分成若干层，每一层都包含若干能力。如图所示，可以清晰地看到建设数据中台需要具备哪些数据能力，这些能力都对应哪些功能模块，分别能解决什么问题。此处不再展开赘述。 三、从中间件工具到平台3.1 ABD总览 图5 ABD总览 中间件工具指DBus、Wormhole、Moonbox、Davinci四大开源平台，它们从敏捷大数据（ABD，Agile BigData）理念中抽象而出，组成ABD平台栈，敏捷数据中台则被我们称为ADX（Agile Data X Platform）。也就是说我们经历了从ABD到ADX的过程。 一开始，基于对业务需求共性的抽象和总结，我们孵化出若干个通用的中间件，去解决各种各样的问题。当出现更为复杂的需求，我们尝试将这些通用的中间件进行组合运用。实践中，我们发现经常会使用到某些特定的组合，同时，从用户角度来看，他们更希望能实现自助化，直接拿过来就能用，而不是每次都要自己去选择和组合。基于这两点，我们对这几个开源工具进行了封装。 3.1.1 ABD-DBusDBus（数据总线平台），是一个DBaaS（Data Bus as a Service）平台解决方案。 DBus面向大数据项目开发和管理运维人员，致力于提供数据实时采集和分发解决方案。平台采用高可用流式计算框架，提供海量数据实时传输，可靠多路消息订阅分发，通过简单灵活的配置，无侵入接入源端数据，对各个IT系统在业务流程中产生的数据进行汇集，并统一处理转换成通过JSON描述的UMS格式，提供给不同下游客户订阅和消费。DBus可充当数仓平台、大数据分析平台、实时报表和实时营销等业务的数据源。 开源地址：https://github.com/BriData ...

一、基于Docker的PaaS平台LAIN在金融的场景下，LAIN 是为解放各个团队和业务线的生产力而设计的一个云平台。LAIN 正式上线已经大约两年，基本已经成熟，为宜信大数据创新中心各个团队提供了统一的测试和生产环境，简化了服务的部署与上线流程，也降低了运维人员对系统管理的复杂度。 LAIN 规范了一个应用的开发、测试、上线工作流，提供了为应用做的容器编排、权限控制、SDN、流量管理、监控报警、备份、日志等 devops 问题的整体解决方案。(扩展阅读：宜信开源|详解PaaS平台LAIN的功能和架构) 在 LAIN 上，应用是一个基本的概念，某个应用的开发者只需要定义一个 lain.yaml 即可定义应用的编译和运行方式，对应用代码侵入性很低。LAIN 基于容器技术，面向多样化的技术栈，并且天然隔离系统和应用的依赖。 当 LAIN 用户创建一个应用（服务）时，可以到 LAIN 上注册该应用，当前的用户自动成为了该应用的维护者，拥有了进一步操作该应用的权限。构建应用的环境需要 docker 和 lain 命令行工具，为了方便，我们创建了一个 vagrant box 即 lain-box. 在构建应用时，除了工程代码外，还需要一个 Docker 镜像作为基础镜像，即编译的环境。如果是二进制的工程，如 golang，则可以在运行时换掉一个底，否则会使用 build 镜像为 release 镜像。准备好镜像和编译／运行的脚本后，就可以编辑 lain.yaml 了。 具体来说，lain.yaml 主要做了如下四件事： 1、应用名称的确定，体现一个应用的边界 2、应用的基础技术栈，即编译和运行的镜像 3、构建过程（如何编译） 4、微服务拆分及服务内部配置（如何运行、运维） 关于第4点，LAIN 上有一个 Proc 的概念，即每个应用都有一个或多个 Proc，Proc 在应用内有唯一的名字和类型，Proc 在底层对应于一组容器，一个应用之间的各个 Proc 的各个容器的网络是互通的，所以应用就是可以互相信任的几个 Proc，对外表现为现实中的某项功能。Proc 的类型是 LAIN 内置的，worker 类型是最简单的类型，LAIN 处理其它的 Proc 类型会做一些额外的事情。 在应用的层面上，LAIN 除了用 lain.yaml 将一个应用的依赖和行为固化外，还有以下几大亮点： 1、SDN 网络安全隔离 使用 calico 项目构建 SDN 网络高效率的应用内网络互通应用间网络默认隔离显式声明应用间的服务互访2、应用权限的控制 ...

LAIN是宜信公司大数据创新中心开发的开源PaaS平台。在金融的场景下，LAIN 是为解放各个团队和业务线的生产力而设计的一个云平台。LAIN 为宜信大数据创新中心各个团队提供了统一的测试和生产环境，简化了服务的部署与上线流程，也降低了运维人员对系统管理的复杂度。 一、设计理念及解决问题LAIN 规范了一个应用的开发、测试、上线工作流，提供了为应用做的容器编排、权限控制、SDN、流量管理、监控报警、备份、日志等 devops 问题的整体解决方案。 在 LAIN 上，应用是一个基本的概念，某个应用的开发者只需要定义一个 lain.yaml 即可定义应用的编译和运行方式，对应用代码侵入性很低。LAIN 基于容器技术，面向多样化的技术栈，并且天然隔离系统和应用的依赖。 当 LAIN 用户创建一个应用（服务）时，可以到 LAIN 上注册该应用，当前的用户自动成为了该应用的维护者，拥有了进一步操作该应用的权限。构建应用的环境需要 docker 和 lain 命令行工具，为了方便，我们创建了一个 vagrant box 即 lain-box. 在构建应用时，除了工程代码外，还需要一个 Docker 镜像作为基础镜像，即编译的环境。如果是二进制的工程，如 golang，则可以在运行时换掉一个底，否则会使用 build 镜像为 release 镜像。准备好镜像和编译／运行的脚本后，就可以编辑 lain.yaml 了。 具体来说，LAIN 解决了以下四个问题： 1、应用开发之下的devops问题的整体解决方案常见问题 面对用户的应用级开发仅仅是冰山一角，在此之下有机房、网络、服务器、系统管理、运维管理、监控、告警、日志等等一系列背后的工作，而这部份的工作可能比应用级开发还要复杂采用IaaS解决了服务器采购和上架问题，但是依然需要一个强大的devops团队来负责上述事务，否则基础设施很容易成为发展瓶颈，且越拖越难解决上面的这些工作对于每一个产品可能都是同质化但又伴随着定制，会消耗大量的时间做这些重复的工作Lain是怎么做的 直接在几乎裸的IaaS或者服务器上即可构建lain集群，方便地进行在线的扩容缩容等集群底层资源操作整合了业界沉淀下来的良好的运维整体实践，提供了冰山下的这一大块工作的整体解决方案将纷繁复杂的系统管理和运维管理行为封装为更简单易用的工具包，极大简化大部分的系统工作，降低日常维护的技术门槛和人力需求将同质化的工作整合在一起，避免重复劳动开箱即用的各种管理组件，囊括了部署，扩容，监控，告警，日志等方方面面。还有附赠应用，包括mysql，redis的集群服务2、规范了应用开发的工作流程，并辅以适当的SCM支援常见问题 在个人开发者以及startup组织中，良好的工作流这件事几乎是不会被提及的，然而在日渐发展的过程中遗留的技术债务却会越来越多的影响开发部署的效率和质量设计、开发和部署行为的不规范会引发各种问题Lain是怎么做的 提供本地开发环境的解决方案提供本地开发过程的SDK / CLI工具链，使得开发和构建过程是嵌入在解决方案中的隐性的提供了SCM支援，约束了开发者的开发和发布行为3、提高整体资源利用率，优化冗余资源池常见问题 传统的按照产品线规划资源池的情况下，会给各产品预留专属的资源池以及配备冗余，以便进行灾备以及服务突发流量然而各产品线的资源需求类型不同，冗余类型也不同，无法共通共享，造成众多的重复冗余，资源利用率比较低通过服务器资源的冗余，扩容缩容，以及资源迁移的操作比较复杂，时间消耗大，风险高Lain是怎么做的 通过容器技术的资源隔离和控制，实现多种技术栈多种应用在集群内安全的不相互影响的混合部署，通过统一的资源池进行冗余，有效提高资源利用率容器技术的运用使得对下资源的使用形成完全统一的形式，扩容缩容以及迁移的成本很低，操作也更简单。4、TBD：架构上提供了服务治理的可能性和解决方案二、特征在应用的层面上，LAIN 还有以下特征： 1、基于配置文件定义应用 在现有的应用上只需要增加一个配置文件lain.yaml即可定义应用在lain集群里的编译和运行对应用代码的侵入性很低2、SDN网络安全隔离 使用开源的calico(https://github.com/projectcal...高效率的应用内网络互通应用间网络默认隔离显式声明应用间的服务互访3、基于容器技术支持多样化的技术栈 使用开源的docker项目构建容器云扩展封装Dockerfile，使用自定义的yaml格式进行应用的集群定义只需符合最简单的lain cluster runtime interface，可自由选择base image容器技术天然的支持隔离系统和应用的依赖 lain SDK / CLI以及可选的ci组件支援代码版本和镜像之间的对应关系编译时和运行时镜像均可完全定制和隔离4、应用在线扩容缩容 使用开源的swarm调度应用部署深度封装swarm docker API，自行开发集群控制器（deployd）以及应用控制器（console） 直接支持用户API调用进行容器实例数扩容，缩容直接支持用户API调用进行容器单实例资源的扩容，缩容（CPU，MEM）5、节点在线扩容缩容 使用开源的ansible(https://github.com/ansible/an...集群的服务器节点（NODE）兼容同一个C段内的物理服务器，虚拟机，公有云服务器集群管理工具包支持add NODE 和 remove NODE 指令，快速进行底层资源扩容和缩容6、服务自动维持和灾难恢复 ...

作者：韩锋 出处：DBAplus社群分享 Themis开源地址：https://github.com/CreditEaseDBA 拓展阅读：宜信开源|数据库审核软件Themis的规则解析与部署攻略 【技术沙龙002期】数据中台：宜信敏捷数据中台建设实践|宜信技术沙龙 将于5月23日晚8点线上直播，点击报名 一、面临的挑战1、运维规模及种类 我相信，这也是很多公司、很多DBA正在面临或未来都会面临的一些问题。正是存在问题，促使我们考虑引入数据库审核平台。 首先是运维规模与人力资源之间的矛盾。从我们的情况来看，运维了包括Oracle、MySQL、MongoDB、Redis四类数据库，数据库规模几十套，支持公司千余名开发人员及上百套业务系统。也许有的朋友会问，从运维规模上看，并不是很大。 的确，与很多互联网公司相比，数据库数十套的估摸并不是太大；但与互联网类公司不同，类似宜信这类金融类公司对数据库的依赖性更大，大量的应用是重数据库类的，且其使用复杂程度也远比互联网类的复杂。DBA除了日常运维（这部分我们也在通过自研平台提升运维效率）外，还需要有大量精力应对数据库设计、开发、优化类的工作。当面对大量的开发团队需要服务时，这个矛盾就更加凸显出来。 2、案例结构设计 第二个挑战，是数据库设计、开发质量参差不齐的问题。 上图就展示了一个结构设计问题。某核心系统的核心表，在这个系统运行的SQL中，28%都是跟这个对象有关的。当我们分析其结构时，发现了很多的问题： 表的规模很大，从设计之初就没有考虑到拆分逻辑（例如分库、分表、分区设计），也没有必要的数据库清理、归档策略。表存在100多个字段，字段数很多且不同字段使用特征也不一致，没有考虑到必要拆表设计。表有13个索引，数目过多。表的索引过度，势必会影响其DML效率。还存在一个索引，在持续监控中发现，其从未被使用过。显然这是一个“多余”的索引。还有两个字段存在重复索引的现象，这也说明在建立索引之初是比较随意的。单个记录定义长度为5800多个字节，但实际其平均保存长度只有不到400字节，最大长度也不长。分析其字段内容，还发现有3个字段类型定义异常。即没有使用应有的类型保存数据，例如使用数字类型保存日期。综上所述，这个表设计的问题还有很多，而且这个表非常重要，大量语句访问和其相关。 SQL语句 上图展示的是一个语句运行效率的问题。从字面可见，两个表做关联查询，但在指定条件时没有指定关联条件。在下面的执行计划中可见，数据库采用了笛卡尔积的方式运行。从后面的成本、估算时间等可见，这是一个多么“巨大”的SQL。其在线上运行的影响，可想而知。 也许有人会说，这是一个人为失误，一般不会发生。但我要说的是，第一，人为失误无法避免，谁也不能保证写出SQL的运行质量；第二，开发人员对数据库的理解不同，很难保证写出的SQL都是高效的；第三，开发人员面临大量业务需求，经常处理赶工状态，很难有更多的精力放在优化上面。这因为有这些问题，线上语句执行质量就成了DBA经常面临的挑战之一。 3、重心转移 这是一张很经典的图，它描述了和数据库相关工作的职能划分。作为DBA，除了面临以上挑战外，从数据库工作发展阶段及自身发展需求来看，也面临一个重心的转移：原有传统DBA的运维职能逐步被弱化，大量的工具、平台的涌现及数据库自我运维能力的提升，简化DBA的工作；紧随而来的数据库架构、结构设计、SQL质量优化逐步成为重点；再往上层的数据治理、建模等工作也越来越受到一些公司的重视。由此可见，DBA未来工作的中心也逐步上移。对中间数据逻辑结构部分，也需要一些工具、平台更好地支撑DBA的工作。 除上述情况外，我司还存在几种的不平衡。 从DBA日常工作来看，传统运维工作还是占了较大的比重，而架构优化类则相对较少。通过引入这一平台，可以帮助DBA更方便地开展架构、优化类工作。公司使用了较多的商业产品，而开源则使用较少。从公司长远战略来看，开源产品的使用会越来越多。从功能角度来看，商业产品相较于开源产品是有优势的。基于开源产品的软件开发，对开发者自身技术技能要求更高。希望通过引入这一产品，可以更容易完成这一转型过程。没有平台之前，DBA还是大量通过手工方式设计、优化数据库，其效率十分低下。特别是面对众多产品线、众多开发团队时，往往感觉力不从心。公司自有团队人员上，还是以初中级为主，中高级人员相对较少。如何快速提升整体设计、优化能力，保证统一的优化效果成为摆在面前的问题。 正是有了上述多种的不平衡，促使我们考虑引入工具、平台去解决数据库质量问题。 我刚来到公司时，看到公司的这些问题，也曾考虑通过制度、规范的形式进行解决。一开始就着手制定了很多的规范，然后在各个部门去培训、宣讲。这种方式运行一段时间后，暴露出一些问题： 整体效果改善并不明显。实施效果取决于各个部门的重视程度及员工的个人能力。规范落地效果无法度量，也很难做到量化分析。往往只能通过上线运行结果来直观感知。缺乏长期有效的跟踪机制。无法对具体某个系统长期跟踪其运行质量。从DBA的角度来看，面对大量的系统，很难依据每个规范，详细审核其结构设计、SQL运行质量。面临上述这些挑战、现存的各种问题，该如何解决？ 经过讨论，最后大家一致认为，引入数据库审核平台，可以帮助解决上面所述问题。 二、平台的选型1、业内做法 在项目之初，我考察了业内其它企业是如何数据库审核的，大致可分为三个思路： 第一类，是以BAT公司为代表的互联网类公司。它们通过自研的SQL引擎，可实现成本分析、自动审核、访问分流、限流等，可做到事前审核、自动审核。但技术难度较大，公司现有技术能力明显不足。 第二类，是通过自研工具收集DB运行情况，根据事前定义规则进行审核，结合人工操作来完成整个审核流程。这种方案只能做到事后审核，但技术难度较小，灵活度很大。其核心就是规则集的制定，可根据情况灵活扩展。 第三类，是一些商业产品，实现思路类似第二类，但是加上一些自主分析能力，功能更为强大，但仍需人工介入处理且需要不小资金投入。而且考察几款商业产品，没有能完全满足所需功能的。 综合上面几类做法，最终确定我们采用“工具+人工审核”的方式，自研自己的审核平台。 2、我们的选择——自研 在启动研发这一平台之初，我们就在团队内部达成了一些共识。 DBA需要扭转传统运维的思想，每个人都参与到平台开发过程中。过去我们积累的一些内容（例如前期制定的规范）可以作为知识库沉淀下来，并标准化，这些为后期规则的制定做好了铺垫。在平台推进中，从最简单的部分入手，开发好的就上线实施，观察效果；根据实施效果，不断修正后面的工作。结合我们自身的特点，定制目标；对于有些较复杂的部分，可果断延后甚至放弃。参考其它公司或商业产品的设计思想，大胆引入。三、审核平台实践下面来看看，审核平台的基本功能及实现原理及方法，这部分是本次分享的重点。 1、平台定位 在项目之初，我们就平台的定位做了描述： 平台的核心能力是快速发现数据库设计、SQL质量问题。平台只做事后审核，自主优化部分放在二期实现。当然在项目设计阶段引入这个，也可以起到一部分事前审核的功能。通过Web界面完成全部工作，主要使用者是DBA和有一定数据库基础的研发人员。可针对某个用户审核，可审核包括数据结构、SQL文本、SQL执行特征、SQL执行计划等多个维度。审核结果通过Web页面或导出文件的形式提供。平台需支持公司主流的Oracle、MySQL，其它数据库放在二期实现。尽量提供灵活定制的能力，便于日后扩展功能。2、平台使用者 作为平台的两类主要使用方，研发人员和DBA都可以从平台中受益。 对于研发人员而言，只用这平台可方便定位问题，及时进行修改；此外通过对规则的掌握，也可以指导他们设计开发工作。对于DBA而言，可快速掌握多个系统的整体情况，批量筛选出低效SQL，并可通过平台提供的信息快速诊断一般性问题。3、实现原理 整个平台的基本实现原理很简单，就是将我们的审核对象（目前支持四种），通过规则集进行筛选。符合规则的审核对象，都是疑似有问题的。平台会将这些问题及关联信息提供出来，供人工甄别使用。由此可见，平台的功能强大与否，主要取决于规则集的丰富程度。平台也提供了部分扩展能力，方便扩展规则集。 4、平台设计审核对象 在开始介绍平台实现之前，再来熟悉下“审核对象”这个概念。目前我们支持的有四类对象，分别说明一下。 对象级。这里所说的对象就是指数据库对象，常见的表、分区、索引、视图、触发器等等。典型规则，例如大表未分区等。语句级。这里所说的语句级，实际是指SQL语句文本本身。典型规则，例如多表关联。执行计划级。这里是指数据库中SQL的执行计划。典型规则，例如大表全表扫描。执行特征级。这里是指语句在数据库上的真实执行情况。典型规则，例如扫描块数与返回记录比例过低。需要说明一下，这四类审核对象中，后三种必须在系统上线运行后才会抓取到，第一种可以在只有数据结构的情况下运行(个别规则还需要有数据)。 此外，上述规则中，除了第二类为通用规则外，其他都与具体数据库相关。即每种的数据库，都有自己不同的规则。 架构简图 这里画出是系统架构框架简图，我简单说明一下。 图中的方框部分，为平台的主要模块。底色不同的模块，表示当前的进度状态不同。虚线代表数据流，实线代表控制流。其核心为这几个模块： 数据采集模块。它是负责从数据源抓取审核需要的基础数据。目前支持从Oracle、MySQL抓取。OBJ/SQL存储库。这是系统的共同存储部分，采集的数据和处理过程中的中间数据、结果数据都保存在这里。其核心数据分为对象类和SQL类。物理是采用的MongoDB。核心管理模块。图中右侧虚线部分包含的两个模块：SQL管理和OBJ管理就是这部分。它主要是完成对象的全生命周期管理。目前只做了简单的对象过滤功能，因此还是白色底色，核心的功能尚未完成。审核规则和审核引擎模块。这部分是平台一期的核心组件。审核规则模块是完成规则的定义、配置工作。审核引擎模块是完成具体规则的审核执行部分。优化规则和优化引擎模块。这部分是平台二期的核心组件。目前尚未开发，因此为白色底色。系统管理模块。这部分是完成平台基础功能，例如任务调度、空间管理、审核报告生成、导出等功能。流程图 让我们从处理流程的角度，看看平台的整体处理过程。 1) “规则管理”部分，这部分主要完成以下一些功能。 初始化规则。平台本身内置了很多规则，在这一过程中到导入到配置库中。新增规则。平台本身提供了一定的扩展能力，可以依据规范新增一条规则。修改规则。可以根据自身情况开启或关闭规则。对于每条规则，还内置了一些参数，也可在此处修改。此外，针对违反规则的情况，还可以设置扣分方法（例如违反一次扣几分、最多可扣几分）等。规则本身及相关参数、配置信息等都会存储在配置库中。2) “任务管理”部分，这是后台管理的一个部分，主要完成与任务相关的工作。系统中的大多数交互都是通过作业异步完成的。其后台是通过celery+flower实现的。 3) “数据采集”部分，这部分是通过任务调度定时出发采集作业完成，也有少量部分是实时查询线上库完成的。采集的结果保存在数据库中，供后续分析部分调用。 4) “规则解析”部分，这部分是由用户通过界面触发，任务调度模块会启动一个后台异步任务完成解析工作。之所以设计为异步完成，主要是审核工作可能时间较长（特别是选择审核类别较多、审核对象很多、开启的审核规则较多）的情况。审核结果会保存在数据库中。 5) “任务查看、导出”部分，在用户发起审核任务后，可在此部分查看进度（处于审核中、还是审核完成）。当审核完成后，可选择审核任务，浏览审核结果或选择导出均可。如果是选择导出的话，会生成异步后台作业生成文件，放置在下载服务器上。 以上就是整个审核的大体流程。后续将看到各部分的详细信息。 ...

TiDB Binlog 组件用于收集 TiDB 的 binlog，并准实时同步给下游，如：TiDB/MySQL等。该组件在功能上类似于 MySQL 的主从复制，会收集各个 TiDB 实例产生的 binlog，并按事务提交的时间排序，全局有序的将数据同步至下游。利用 TiDB Binlog 可以实现数据准实时同步到其他数据库，以及 TiDB 数据准实时的备份与恢复。TiDB Binlog 作为 TiDB 的核心组件之一，已经在上百家用户的生产环境中长时间稳定运行。 为方便用户和开发者更加深入理解和使用 TiDB Binlog 组件，以及基于 TiDB Binlog 组件做二次开发用于更多的业务场景， 我们决定今天正式开源 TiDB Binlog 组件。 TiDB Binlog 适用的功能场景准实时数据同步：同步 TiDB 数据到其他数据库或消息队列（如TiDB/MySQL/MariaDB/Kafka）。准实时备份和恢复：增量备份 TiDB 集群数据到外部系统，利用备份的数据在系统故障或者其他场景时可将数据恢复到任意时间点。TiDB Binlog 架构 TiDB Binlog 核心特性支持类似 MySQL ROW 复制模式。准实时并按事务提交的时间顺序将数据同步至下游。分布式架构设计，支持水平弹性扩容和服务高可用。数据高可靠，系统实时将数据持久化到本地磁盘。支持多种输出方式，如下： 文件：系统准实时将 binlog 写入文件系统作为增量备份，利用此增量备份文件可将数据恢复到任意时间点。消息队列：按照 binlog slave protocol 输出到 Kafka。下游目标数据库：TiDB/MySQL/MariaDB。TiDB Binlog 代码及文档资源TiDB Binlog 源代码TiDB Binlog 使用手册深入理解 TiDB Binlog 组件实现原理定制输出方式或者输出到其他下游存储系统欢迎大家一起参与 TiDB Binlog 的设计、研发、测试共同推进 TiDB Binlog 走向更成熟，更稳定。近期我们将发布 TiDB Binlog 源码阅读指南，敬请期待。 ...

导读：数据虚拟化思想一直以来都是敏捷大数据团队十分关注的一个点，Moonbox则以此为基础而设计，致力于提供批量计算服务解决方案。今天，Moonbox惊喜发布0.3beta版（回顾v0.2请戳这里：#Moonbox# 计算服务平台简介），阅读全文，了解Moonbox，跟小编一起看0.3版本的神奇之处在哪里吧~ Project：https://github.com/edp963/moo...Release：https://github.com/edp963/moo...Documentation：https://edp963.github.io/moon...一、Moonbox定位在了解Moonbox新版本之前，我们先来回忆一下Moonbox的定位。 Moonbox是一个DVtaaS（Data Virtualization as a Service）平台解决方案。它基于数据虚拟化设计思想，致力于提供批量计算服务解决方案。Moonbox负责屏蔽底层数据源的物理和使用细节，为用户带来虚拟数据库般使用体验，用户只需通过统一SQL语言，即可透明实现跨异构数据系统混算和写出。此外Moonbox还提供数据服务、数据管理、数据工具、数据开发等基础支持，可支撑更加敏捷和灵活的数据应用架构和逻辑数仓实践。 二、Moonbox功能数据虚拟化思想是Moonbox很重要的一个设计原则，在此基础上，Moonbox实现了多种功能。下面我们具体看一下Moonbox都有哪些功能： 多租户Moonbox建立了一套完整的用户体系，引入了Organization的概念，用于划分用户空间。系统管理员ROOT账号可以创建多个Organization，并在Organization中指定该Organization的管理者（SA）。SA可以是一个或者多个，SA负责创建管理普通用户。 Moonbox将普通用户的能力抽象出六大属性，分别是是否可以执行Account管理语句，是否可以执行DDL语句，是否可以执行DCL语句, 是否拥有可以授权其他用户执行Account类语句的能力，是否拥有可以授权其他用户执行DDL语句的能力，是否拥有可以授权其他用户执行DCL语句的能力。通过属性的自由组合，可以构建出满足多种角色，多种需求的用户体系模型，并借此实现多租户。 扩展SQLMoonbox将查询语言统一为Spark SQL，底层使用Spark进行计算，同时扩展了一套DDL、DCL语句。包括对用户的创建删除和授权，数据表或者数据列的访问授权，挂载卸载物理数据源或者数据表，创建删除逻辑数据库，创建删除UDF/UDAF，创建删除定时任务等。 优化策略Moonbox基于Spark进行混算，Spark SQL是支持多数据源的，但是Spark SQL在从数据源中进行数据拉取的时候只进行了project和filter算子的下推，并没有考虑数据源的算力特性。 比如Elasticsearch对于聚合操作是很友好的，如果聚合操作能下推到Elasticsearch中进行计算会比将数据全部拉回Spark计算快的多。 再比如limit算子如果下推到数据源计算，能大大减少返回的数据量，节省拉取数据和计算的时间。 Moonbox对Spark Optimizer优化后的LogicalPlan作进一步的优化，根据规则拆分出可以进行下推的子树，将子树mapping成数据源查询语言，将下推结果拉回Spark参与进一步的计算。 另外，如果LogicalPlan可以整体下推计算，那么Moonbox将不采用Spark进行计算，而是直接使用数据源客户端运行LogicalPlan mapping出来的查询语句，以减少启动分布式作业的开销，并节省分布式计算资源。 列权限控制Moonbox定义了DCL语句来实现数据列级别权限控制。Moonbox管理员通过DCL语句将数据表或者数据列授权给用户，Moonbox会将用户和表以及列的权限关系保存到catalog中。当用户在使用SQL查询时会被拦截，分析出SQL被解析后的LogicalPlan中是否引用了未被授权的表或者列，如果有就报错返回给用户。 多种形式的UDF/UDAFMoonbox除了支持以jar包的形式创建UDF/UDAF外，还支持以源代码的形式创建，包括Java语言和Scala语言，这给UDF开发验证带来了便捷性。 定时任务Moonbox提供了定时任务的功能，用户使用DDL语句定义定时任务，以crontab表达式的形式定义调度策略，后台内嵌quartz进行任务定时调度。 多种客户端Moonbox支持以命令行工具, JDBC, Rest, ODBC等方式进行访问。 多种数据源支持Moonbox支持多种数据源，包括MySQL, Oracle, SQLServer, Clickhouse, Elasticsearch, MongoDB, Cassandra, HDFS, Hive, Kudu等，且支持自定义扩展。 两种任务模式Moonbox支持Batch和Interactive两种任务模式。Batch模式支持Spark Yarn Cluster Mode，Interactive模式支持Spark Local和Spark Yarn Client Mode。 集群工作模式Moonbox以master-slave群集方式工作，支持master主备切换。 三、Moonbox_v0.3 VS v0.2Moonbox_v0.3在v0.2的基础上做出了几点重要改变，具体包括： 去掉redis依赖v0.2是将查询结果写入Redis然后客户端从Redis中获取结果；v0.3直接将结果返回给客户端。 改变数据传输方式v0.2客户端以rest方式获取结果数据；v0.3使用netty加protobuf的方式获取结果数据。 Moonbox Master选主策略重构将Moonbox Master选主由akka singleton改为使用zk进行选主和信息持久化。 Moonbox Worker与Spark解耦在v0.2中，直接在Worker中运行Spark APP Driver；v0.3改为在新的进程中运行Spark APP Driver，这样Worker就与Spark进行了解耦，一个Worker节点可以运行多个Spark APP Driver，且可以运行其他APP。 ...

导语：宜信于2019年3月29日正式开源nextsystem4（以下简称“NS4”）系列模块。此次开源的NS4系列模块是围绕当前支付系统笨重、代码耦合度高、维护成本高而产生的分布式业务系统解决方案。NS4系列框架允许创建复杂的流程/业务流，对于业务服务节点的实现可串联，可分布式。其精简、轻量，实现了“脱容器”（不依赖tomcat、jetty等容器）独立运行。NS4系列框架的设计理念是将业务和逻辑进行分离，开发人员只需通过简单的配置和业务实现就可以实现逻辑复杂、性能高效、功能稳定的业务系统。点击查看框架整体介绍 NS4系列包括4个开源模块，分别是：ns4_frame分布式服务框架（详情点击查看：开源|ns4_frame分布式服务框架开发指南）、ns4_gear_idgen ID生成器组件（NS4框架Demo示例）（详情点击查看：开源|为什么要使用ns4_gear_idgen ID生成器？）、ns4_gear_watchdog 监控系统组件（服务守护、应用性能监控、数据采集、自动化报警系统）和ns4_chatbot通讯组件。本文将重点介绍ns4_chatbot通讯组件的工作原理。 项目开源地址：https://github.com/newsettle/... 一、项目简介ns4_chatbot是针对业务的一个聊天机器人的聊天框架，集成了qqbot、wxchat、rasa以及web服务。提供微信和QQ聊天接口，可以对某个群组发送系统监控消息等。QQ和微信聊天机器人都无法直接发消息给群组中的非好友用户，只能通过@的的方式提醒。 微信聊天机器人 使用的是开源的wxpy 机器人框架。使用@register这种python wapper机制来绑定消息响应函数。微信机器人需要对群组进行注册才能对消息进行发送。 QQ聊天机器人 采用酷Q方案。酷Q是windows下的一个程序，可以模拟QQ。在linux系统中，采用wine技术。需要单独部署成为一个docker，然后通过一个http的接口暴露，各类http接口，用来让我们发送消息。提供http消息回调。 二、全局目录结构 三、实现功能接受内部系统（如监控系统）的系统调用，从而把消息推送给QQ或者微信用户。内部系统调用服务的时候，需要提供以下信息 发给哪个群组发给这个群组中的那个用户发送的消息可以接受QQ、微信用户的对话，理解其意图，并且回应用户。四、项目部署&安装此项目主要针对linux系统，采用python2.7+环境进行部署说明。 4.1 依赖环境安装安装必需依赖包:取项目中的 ns4_chatbot/requirements.txt 文件，运行pip install –r requirements.txt命令安装redis安装mysql数据库，导入ns4_chatbot/import_data/production/ddl.sql 文件4.2 酷Q聊天机器人安装酷Q目前可以在Wine中运行，见酷Q Air / Pro on Wine，因此也就自然而然有了相应的Docker镜像coolq/wine-coolq。 要在Docker中使用本插件，可以使用酷Q官方的Docker镜像，然后在其中安装本插件(下载cpk、编辑配置文件、启用插件)，也可以使用维护的已安装并启用了插件的镜像 richardchien/cqhttp(基于酷Q官方的镜像修改)。 下面介绍这个镜像的用法。 docker 安装sudo apt-get install -y docker.io 酷Q安装$ docker pull richardchien/cqhttp:latest $ mkdir coolq# 用于存储酷 Q 的程序文件$ docker run -ti --rm --name cqhttp-test \# 将宿主目录挂载到容器内用于持久化酷 Q 的程序文件-v $(pwd)/coolq:/home/user/coolq \-p 9000:9000 \ # noVNC 端口，用于从浏览器控制酷 Q-p 5700:5700 \ # HTTP API 插件开放的端口-e COOLQ_ACCOUNT=123456 \ # 要登录的 QQ 账号，可选但建议填-e CQHTTP_POST_URL=http://example.com:8080 \ # 事件上报地址# 允许通过 HTTP 接口访问酷 Q 数据文件 -e CQHTTP_SERVE_DATA_FILES=yes \ richardchien/cqhttp:latest配置酷Q回调地址:在/coolq/app/io.github.richardchien.coolqhttpapi/config/<QQ_ID>.ini 中添加 post_url=http://[IP]:8080/coolq_callback 酷Q启动:在浏览器中输入 http://[ip]:5700, 进入如下页面: ...

本文来自于我的慕课网手记：开篇-分布式系统中的那些开源软件，转载请保留链接 ;)我们来讨论一个大型话题，把分布式系统所能采用的开源或者商业软件，方方面面都来讨论一下。这里做个记录，也算是我加入慕课网认证作者的一个里程碑，今后的文章也是会和这些软件相关的，毕竟单体的项目已经不复返，分布式的项目已经成为了主流。不管你看到这个大纲可能有的熟悉，还是有的不了解，没关系，我们今后会一个个掰开的学习掌握它们，（熟悉的就要更加熟悉，不会的就要学会并掌握它。）当然，这篇文章不能代表所有分布式所用到的技术，也欢迎各位在后面评论中留言补充。基础框架Spring Cloud，Dubbo，Motan，Sofa分布式注册中心Eureka（Netflix），Consul，Nacos，Etcd，Zookeeper分布式监控中心CAT，SBA，Prometheus，Grafana分布式配置中心Apollo，Nacos，DisConf，Spring Cloud Config分布式网关F5，Ngnix+（打通Consul），ESB，Kong，zuul, gateway分布式事务Seata，dts，tcc-transaction，hmily，ByteTCC，myth，EasyTransaction，tx-lcn分布式日志系统ELK(Kibana，ElasticSearch，Logstash)，Kafka，Flume，Splunk分布式定时任务调度和管理Elastic Job，XXL Job分布式限流熔断降级Sentinel，Redis，Guava分布式服务权限控制系统OAuth，JWT，单点登录，Hystrix，shiro分布式监控中心CAT，SBA，Prometheus，Grafana，Graphite，Statsd，Solarwinds，Zabbix，Centreon，appDynamics，new relic，Kaeger分布式服务和系统诊断Arthas分布式调用链CAT，SkyWalking+RocketBolt，Zipkin，DynaTrace分布式流程和服务编排Coroutine，Akka，Kilim，Flowable，Axon分布式锁Redisson，Redis，Zookeeper分布式压测平台JMeter，LoadRunner分布式全局主键系统Redis，Zookeeper，Twitter Snowflake分布式自动化测试Postman、Jenkins分布式自动化API文档Swagger分布式分库分表中间件多数据源Sharding Sphere，MyCat分布式消息队列中间件RocketMQ，Kafka，ActiveMQ，Tibco分布式缓存Redis、MongoDB分布式数据库分析诊断系统慢SQL，听云分布式自动化数据库脚本升级Flyway异构系统Spring Cloud Sidecar，Service Mesh，istio，Sofa mesh异构网关运维发布DevOps，CICD和Pipeline，容器(Docker)化，K8S，Jenkins，蓝鲸，TriAquae，Choerodon（猪齿鱼）

导语：宜信于2019年3月29日正式开源nextsystem4（以下简称“NS4”）系列模块。此次开源的NS4系列模块是围绕当前支付系统笨重、代码耦合度高、维护成本高而产生的分布式业务系统解决方案。NS4系列框架允许创建复杂的流程/业务流，对于业务服务节点的实现可串联，可分布式。其精简、轻量，实现了“脱容器”（不依赖tomcat、jetty等容器）独立运行。NS4系列框架的设计理念是将业务和逻辑进行分离，开发人员只需通过简单的配置和业务实现就可以实现逻辑复杂、性能高效、功能稳定的业务系统。点击查看框架整体介绍NS4系列包括4个开源模块，分别是：ns4_frame 分布式服务框架（详情点击查看：开源|ns4_frame分布式服务框架开发指南）、ns4_gear_idgen ID生成器组件（NS4框架Demo示例）、ns4_gear_watchdog 监控系统组件（服务守护、应用性能监控、数据采集、自动化报警系统）和ns4_chatbot通讯组件。其中，ns4_gear_idgen（ID生成器）是基于ns4_frame框架实现的，它支持分布式部署，生成全局唯一的 ID，其中长度、前缀、后缀、步长、进制也可根据自己的业务自由配置，还可以通过ns4_gear_idgen对NS4.0框架进行测试。本文重点介绍ns4_gear_idgen （ID生成器）方案具备哪些优点。项目开源地址：https://github.com/newsettle/…一、引子在复杂的系统中，往往需要使用一个有意义且有序的序列号来作为全局唯一的ID，来对大量的数据（如订单账户）进行标识。二、业内方案简介2.1 时间戳方案取当前毫秒数/微秒作为ID ，如System.currentTimeMillis()优点本地生成ID，不需要进行远程调用，时延低。生成的ID趋势递增。生成的ID是整数，建立索引后查询效率高。缺点并发量过高，会生成重复的ID。不能高可用，存在单点故障问题。不够灵活，不能实现对不同业务的ID隔离。2.2 UUID 方案UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符。示例：550e8400-e29b-41d4-a716- 446655440000，到目前为止业界一共有 5 种方式生成UUID，详情见IETF发布的UUID规范 A Universally Unique IDentifier (UUID) URN Namespace。 优点性能非常高：本地生成，没有网络消耗。缺点不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。无序ID：于ID之前毫无顺序可言。ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用:A：MySQL官方有明确的建议主键要尽量越短越好[4]，36 个字符长度的UUID不符合要求。All indexes other than the clustered index are known as secondary indexes. In InnoDB, each record in a secondary index contains the primary key columns for the row, as well as the columns specified for the secondary index. InnoDB uses this primary key value to search for the row in the clustered index. If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.B：对MySQL索引不利。如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能。2.3 Snowflake 方案这种方案大致来说是一种以划分命名空间(UUID也算，由于比较常见，所以单独分析)来生成ID的一种算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示。如下图(图片来自网络)所示: 41-bit的时间可以表示(1L<<41)/(1000L360024*365)=69年的时间，10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器，可以根据自身需求定义。12 个自增序列号可以表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。 优点毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。可以根据自身业务特性分配bit位，非常灵活。缺点强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。不够灵活，不能实现对不同业务的ID隔离。2.4 数据库 auto_increment 方案以MySQL举例，利用给字段设置auto_increment_increment和 auto_increment_offset来保证ID自增，每次业务使用下列SQL读写MySQL得到ID号。begin;REPLACE INTO Tickets64 (stub) VALUES (‘a’);SELECT LAST_INSERT_ID();commit;优点非常简单，利用现有数据库系统的功能实现，成本小，有DBA专业维护。ID号单调自增，可以实现一些对ID有特殊要求的业务。缺点强依赖DB，当DB异常时整个系统不可用，属于致命问题。配置主从复制可以尽可能的。增加可用性，但是数据一致性在特殊情况下难以保证。主从切换时的不一致可能会导致重复发号。ID发号性能瓶颈限制在单台MySQL的读写性能。2.5 redis 生成 IDRedis的所有命令操作都是单线程的，本身提供像incr和increby这样的自增原子命令，所以能保证生成的ID肯定是唯一有序的。考虑到单节点的性能瓶颈，可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1, 2, 3, 4, 5，然后步长都是5。各个Redis生成的ID为: A:1, 6, 11, 16, 21B:2, 7, 12, 17, 22C:3, 8, 13, 18, 23 D:4, 9, 14, 19, 24 E:5, 10, 15, 20, 25 优点不依赖于数据库，灵活方便，且性能优于数据库。数字ID天然排序，对分页或者需要排序的结果很有帮助。使用集群可以防止单点故障问题。缺点如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。需要编码和配置的工作量比较大。步长、初始值需提前确定好且不易于扩展。2.6 ns4_gear_idgen 方案先看下数据库表设计: 字段说明:id：数据库主键，无实际含义。key_name ：用来区分业务，不同的业务使用不同的。key_name，每个key_name的ID相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对 biz_tag 分库分表就行。key_value：表示该key_name目前所被分配的ID号段的最大值。key_length：生成ID的长度。key_cache：表示每次分配的号段长度。原来获取ID每次都需要写数据库，现在只需要把key_cache设置得足够大，比如1000。那么只有当 1000个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从1减小到了1/step。key_prefix：生成ID的前缀，可配置自定义前缀+日期部分 如: ${date14}/TEST${date14}ID前缀日期部分支持以下几种日期格式:key_suffix=：生成ID的后缀，可配置亦可不配置key_digit:ID 进制数，支持10进制36进制62进制 。Version：每条记录对应的版本号，用户更新记录。优点很方便的线性扩展，能够支撑大多数业务场景。生成ID规则多样，可配置且支持10进制、36进制、62进制。业务之间ID相互隔离，互不影响。获取ID不用频繁操作数据库，快消耗完号段内ID时才会操作数据库，减轻了数据库的压力。提前初始化号段内的ID，保证在每个号段内ID使用完之前初始化完成，避免业务使用完ID后才初始化带来的影响。可以自定义key_value的大小，非常方便业务从原有的ID方式上迁移过来。容灾性高：服务内部有号段缓存，即使 DB 宕机，短时间内服务仍能正常对外提供服务。三、 功能介绍该ID生成器是基于NS4框架实现的，支持分布式部署，同时生成的ID长度、前缀、后缀、步长，进制也可根据自己的业务自由的配置。其功能可分为以下几个部分:获取单个 Long 类型的 ID 如 66310获取批量 String 类型的 ID:19011123221266312, 19011123221266313, 19011123221266314, 19011123221266315四、 请求方式五、 SQL脚本见 ns4_gear_idgen 源码下 gear_key.sql 内容来源：宜信技术学院 ...

添加许可非常简单，首先找到项目当前的开发分支，在主页 README.md 的开头加入下面的内容即可：<p> <a href=“https://github.com/996icu/996.ICU/blob/master/LICENSE_CN"> <img alt=“996icu” src=“https://img.shields.io/badge/license-NPL%20%28The%20996%20Prohibited%20License%29-blue.svg"> </a></p>你将会看到这样一个图标：可能你的项目无足轻重，但只要你还在维护，就不妨把它加进去，让我们从形成一种风气开始做起！

说明在 Spring boot web 中我们可以通过 RequestContextHolder 很方便的获取 request。ServletRequestAttributes requestAttributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();// 获取 requestHttpServletRequest request = requestAttributes.getRequest();不再需要通过参数传递 request。在 Spring webflux 中并没提供该功能，使得我们在 Aop 或者一些其他的场景中获取 request 变成了一个奢望？？？寻求解决方案首先我想到的是看看 spring-security 中是否有对于的解决方案，因为在 spring-security 中我们也是可以通过 SecurityContextHolder 很方便快捷的获取当前登录的用户信息。找到了 ReactorContextWebFilter，我们来看看 security 中他是怎么实现的。https://github.com/spring-pro…public class ReactorContextWebFilter implements WebFilter { private final ServerSecurityContextRepository repository; public ReactorContextWebFilter(ServerSecurityContextRepository repository) { Assert.notNull(repository, “repository cannot be null”); this.repository = repository; } @Override public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) { return chain.filter(exchange) .subscriberContext(c -> c.hasKey(SecurityContext.class) ? c : withSecurityContext(c, exchange) ); } private Context withSecurityContext(Context mainContext, ServerWebExchange exchange) { return mainContext.putAll(this.repository.load(exchange) .as(ReactiveSecurityContextHolder::withSecurityContext)); }}源码里面我们可以看到 他利用一个 Filter，chain.filter(exchange) 的返回值 Mono 调用了 subscriberContext 方法。那么我们就去了解一下这个 reactor.util.context.Context。找到 reactor 官方文档中的 context 章节：https://projectreactor.io/doc…大意是：从 Reactor 3.1.0 开始提供了一个高级功能，可以与 ThreadLocal 媲美，应用于 Flux 和 Mono 的上下文工具 Context。更多请大家查阅官方文档，对英文比较抵触的朋友可以使用 google 翻译。mica 中的实现mica 中的实现比较简单，首先是我们的 ReactiveRequestContextFilter：/** * ReactiveRequestContextFilter * * @author L.cm /@Configuration@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.REACTIVE)public class ReactiveRequestContextFilter implements WebFilter { @Override public Mono<Void> filter(ServerWebExchange exchange, WebFilterChain chain) { ServerHttpRequest request = exchange.getRequest(); return chain.filter(exchange) .subscriberContext(ctx -> ctx.put(ReactiveRequestContextHolder.CONTEXT_KEY, request)); }}在 Filter 中直接将 request 存储到 Context 上下文中。ReactiveRequestContextHolder 工具：/* * ReactiveRequestContextHolder * * @author L.cm /public class ReactiveRequestContextHolder { static final Class<ServerHttpRequest> CONTEXT_KEY = ServerHttpRequest.class; /* * Gets the {@code Mono<ServerHttpRequest>} from Reactor {@link Context} * @return the {@code Mono<ServerHttpRequest>} */ public static Mono<ServerHttpRequest> getRequest() { return Mono.subscriberContext() .map(ctx -> ctx.get(CONTEXT_KEY)); }}怎么使用呢？mica 中对未知异常处理，从 request 中获取请求的相关信息@ExceptionHandler(Throwable.class)@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)public Mono<?> handleError(Throwable e) { log.error(“未知异常”, e); // 发送：未知异常异常事件 return ReactiveRequestContextHolder.getRequest() .doOnSuccess(r -> publishEvent(r, e)) .flatMap(r -> Mono.just(R.fail(SystemCode.FAILURE)));}private void publishEvent(ServerHttpRequest request, Throwable error) { // 具体业务逻辑}WebClient 透传 request 中的 header此示例来源于开源中国问答中笔者的回复: 《如何在gateway 中获取 webflux的 RequestContextHolder》@GetMapping("/test")@ResponseBodypublic Mono<String> test() { WebClient webClient = testClient(); return webClient.get().uri("").retrieve().bodyToMono(String.class);}@Beanpublic WebClient testClient() { return WebClient.builder() .filter(testFilterFunction()) .baseUrl(“https://www.baidu.com”) .build();}private ExchangeFilterFunction testFilterFunction() { return (request, next) -> ReactiveRequestContextHolder.getRequest() .flatMap(r -> { ClientRequest clientRequest = ClientRequest.from(request) .headers(headers -> headers.set(HttpHeaders.USER_AGENT, r.getHeaders().getFirst(HttpHeaders.USER_AGENT))) .build(); return next.exchange(clientRequest); });}上段代码是透传 web 中的 request 中的 user_agent 请求头到 WebClient 中。开源推荐mica Spring boot 微服务核心组件集：https://gitee.com/596392912/micaAvue 一款基于vue可配置化的神奇框架：https://gitee.com/smallweigit/avuepig 宇宙最强微服务（架构师必备）：https://gitee.com/log4j/pigSpringBlade 完整的线上解决方案（企业开发必备）：https://gitee.com/smallc/SpringBladeIJPay 支付SDK让支付触手可及：https://gitee.com/javen205/IJPay关注我们扫描上面二维码，更多精彩内容每天推荐！转载声明如梦技术对此篇文章有最终所有权，转载请注明出处，参考也请注明，谢谢！ ...

作者：申砾今年 1 月份，我们发布了 TiDB 3.0.0 Beta 版本，DevCon 上也对这个版本做了介绍，经过两个月的努力，今天推出了下一个 Beta 版本 3.0.0 Beta.1。让我们看一下这个版本相比于之前有什么改进。新增特性解读Skyline Pruning查询计划正确性和稳定性对于关系型数据库来说至关重要，3.0.0 Beta.1 对这部分进行了优化，引入一个叫 Skyline Pruning 的框架，通过一些启发式规则来更快更准确地找到最好的查询计划。详细信息可以参考 这篇设计文档。日志格式统一日志是排查程序问题的重要工具，统一且结构化的日志格式不但有利于用户理解日志内容，也有助于通过工具对日志进行定量分析。3.0.0 Beta.1 版本中对 tidb/pd/tikv 这三个组件的日志格式进行了统一，详细格式参见 这篇文档。慢查询相关改进慢查询日志是常用于排查性能问题, 在 3.0.0 Beta.1 之前慢查询日志跟其他日志混合存储在同个日志文件，并且格式为自定义的格式，不支持使用 SQL 语句或工具对其进行分析，严重影响排查问题的效率。从3.0.0 Beta.1 版本开始 TiDB 将查询日志文件输出到单独的日志文件中（默认日志文件名为 tidb-slow.log），用户可以系统变量或配置文件进行修改，同时兼容 MySQL 慢查询日志格式，支持使用 MySQL 生态分析工具（如 pt-query-digest）对慢查询日志进行分析。除了慢查询日志之外，还增加一个虚拟表 INFORMATION_SCHEMA.SLOW_QUERY，可以对慢查询日志进行展示和过滤。关于如何处理慢查询，我们后续还会专门写一篇文档进行介绍。如果你有一些好用的慢查询处理工具，也欢迎和我们进行交流。Window FunctionMySQL 所支持的 Window Function TiDB 3.0.0 Beta.1 版本已经全都支持，这为 TiDB 向 MySQL 8 兼容迈出了一大步。想体验功能的可以下载版本尝鲜，但是不建议在生产中使用，这项功能还需要大量的测试，欢迎大家测试并反馈问题。热点调度策略可配置化热点调度是保持集群负载均衡的重要手段，但是一些场景下默认的热点调度显得不那么智能，甚至会对集群负载造成影响，所以 3.0.0 Beta.1 中增加了对负载均衡策略的人工干预方法，可以临时调整调度策略。优化 Coprocessor 计算执行框架目前已经完成 TableScan 算子，单 TableScan 即扫表性能提升 5% ~ 30%，接下来会对 IndexScan、Filter、Aggregation 等算子以及表达式计算框架进行优化。TiDB Lightning 性能优化Lightning 是将大量数据导入 TiDB 的最佳方式，在特定表结构，单表数量，集群已有数量等条件下 1TB 数据导入性能提升 1 倍，时间从 6 小时降低到 3 小时以内，性能优化的脚步不会停，我们期望进一步提升性能，降低时间，期望能优化到 2 小时以内。易用性相关的特性使用 /debug/zip HTTP 接口， 可以方便地一键获取当前 TiDB 实例的信息，便于诊断问题。新增通过 SQL 语句方式管理 pump/drainer 状态，简化 pump/drainer 状态管理，当前仅支持查看状态。支持通过配置文件管理发送 binlog 策略, 丰富 binlog 管理方式。更多的改进可以参见 Release Notes，除了这些已经完成的特性之外，还有一些正在做的事情，比如 RBAC、Plan Management 都在密集开发中，希望在下一个 Beta 版本或者 RC 版本中能与大家见面。开源社区在这个版本的开发过程中，社区依然给我们很有力的支持，比如潘迪同学一直在负责 View 的完善和测试，美团的同学在推进 Plan Management，一些社区同学参与了 TiDB 性能改进 活动。在这里对各位贡献者表示由衷的感谢。接下来我们会开展更多的专项开发活动以及一系列面向社区的培训课程，希望能对大家了解如何做分布式数据库有帮助。One More ThingTiDB DevCon 2019 上对外展示的全新分析类产品 TiFlash 已经完成 Alpha 版本的开发，目前已经在进行内部测试，昨天试用了一下之后，我想说“真香”。 ...

专栏介绍本套专栏主要是介绍微服务核心框架 Mica 中对 Cglib bean copy 的一系列增强，保证高性能的同时，提高易用性。整个专栏有 6 篇文章，感兴趣的朋友请加关注。专栏目录cglib bean copy 介绍。mica bean copy 介绍和链式 bean copy 的支持。mica bean 支持 copy 原始类型和封装类型。mica bean 支持 copy map 到 bean。使用Spring的类型转换增强 mica bean copy。mica bean、Map 互转增强和总结。Cglib BeanCopier 介绍阿里巴巴 p3c 插件中有这么一项检查 “避免用Apache Beanutils进行属性的copy，Apache BeanUtils性能较差，可以使用其他方案比如Spring BeanUtils, Cglib BeanCopier”。今天我们的主角主要就是 Cglib 的 BeanCopier。性能下图是 github 上的一个 Bean copy 性能的对比，可以看出 Bean copy 工具性能差距还是比较大。更多请见：https://github.com/yangtu222/BeanUtils#performance图中可以看出，Cglib BeanCopier 的性能十分强劲，也难怪阿里巴巴规范中也推荐，下面我们来看看它具体的使用方式。使用Cglib 以源码的形式纳入到 Spring core 中，所有大家使用 Spring、Spring boot 可以直接使用。其它则需要自己添加依赖，下面的使用例子都以 Spring 的为主。注意：使用了 Lombok 。User 对象@Datapublic class User { private Integer id; private String name; private Integer age;}UserVo 对象@Datapublic class UserVo { private String name; private Integer age;}Bean 拷贝import org.springframework.cglib.beans.BeanCopier;public class UserCopyTest { public static void main(String[] args) { // 1. 初始化 user，赋值 User user = new User(); user.setId(250); user.setName(“如梦技术”); user.setAge(30); // 2. 初始化 userVo UserVo userVo = new UserVo(); // 3. 构造 BeanCopier，不是用类型转换 BeanCopier copier = BeanCopier.create(User.class, UserVo.class, false); // 4. 拷贝对象，不是用类型转换，转换器可以使用 null copier.copy(user, userVo, null); // 5. 打印结果：UserVo(name=如梦技术, age=30) System.out.println(userVo); }}原理大家都知道 Cglib BeanCopier，之所以性能这么高主要是利用了 Asm 字节码技术。在 UserCopyTest 的 main 方法中添加下面的代码（建议直接放置到 1. 初始化 user，赋值 之前），指定cglib 源码生成目录，建议生成到 idea 项目中，可以直接打开生成的 class 字节码。// 设置 cglib 源码生成目录String sourcePath = “/Users/lcm/git/mica/mica-example/web-example/src/test/java”;System.setProperty(DebuggingClassWriter.DEBUG_LOCATION_PROPERTY, sourcePath);再次执行 main 方法。我们可以看到控制台打印下了这么一行日志。CGLIB debugging enabled, writing to ‘/Users/lcm/git/mica/mica-example/web-example/src/test/java’下面我们来看看生成的代码：看到此图大家恍然大悟，Cglib BeanCopier 帮我们生成了 get set 转换。Cglib copy 问题不支持链式 bean，mybatis-plus 生成的 Model 中默认添加了 @Accessors(chain = true) 注解默认为链式。不支持 原始类型和封装类型 copy int <-> Integer。类型转换不够智能，设置 useConverter 为 true 和重写 Converter，类型相同也会走转换的逻辑。注意：这部分后面会详细介绍，喜欢的朋友请关注、订阅我们。链接mica：https://github.com/lets-mica/mica如梦技术官网：https://www.dreamlu.net开源推荐Spring boot 微服务高效开发 mica 工具集：https://gitee.com/596392912/micaAvue 一款基于vue可配置化的神奇框架：https://gitee.com/smallweigit/avuepig 宇宙最强微服务（架构师必备）：https://gitee.com/log4j/pigSpringBlade 完整的线上解决方案（企业开发必备）：https://gitee.com/smallc/SpringBladeIJPay 支付SDK让支付触手可及：https://gitee.com/javen205/IJPay加入【如梦技术】Spring QQ群：479710041，了解更多。关注我们扫描上面二维码，更多精彩内容每天推荐！ ...

Linux基金会举办的开源领袖峰会（Open Source Leadership Summit）是一个亲密的、仅限邀请的活动，促进了开放技术开发领域的领先项目和企业之间的创新、发展和合作关系。对于希望推进开源策略、实施和投资的业务和技术领导者来说，这是必须参加的。与会者包括：使用开源软件并与业内其他人共享研发的组织的高管、业务和开源项目办公室负责人负责组织内关键项目或开源策略的技术负责人需要跟领导技术和执行领导层，分享最佳实践和策略以实现最大创新的开源组织和项目负责人今年精彩内容的幻灯片在活动结束后的一周内，在演讲者提供的情况下会陆续发布到网站以供下载：Open Chain at Scania - Jonas Öberg, Scania CV ABSingle-vendor Open Source at the Crossroads - Dirk Riehle, Friedrich-Alexander UniversityInspur’s Opensource Practices and Lessons - James Wang, InspurManaging Open Source Better Together - Michael Picht, SAP & Thomas Steenbergen, HERE TechnologiesOpen Source Collaboration and Companies: Finding the Right Balance - Dawn Foster, PivotalSPDX: Bridging the Compliance Tooling Gap - Steve Winslow & Gary O’Neall, The Linux FoundationEnd-to-end Injection Safety at Scale - Mike Samuel, GoogleThe Future of Open Source Sustainability, as Seen Elsewhere - Jose Miguel Parrella, MicrosoftBridging the Development Gap and the Commercial Use of Open Source Projects - Anni Lai & Sean McGinnis, HuaweiStarting and Scaling an Open Source Office: The Good, the Bad and the Ugly - Thomas Steenbergen, HERE TechnologiesHow Open Source Projects Can Leverage Standards and Specifications - David Rudin, Microsoft Corporation & Joint Development FoundationA Tale of Two Cities - Gil Yehuda & Ashley Wolf, Verizon MediaFulfilling Open Source License Obligations: Can Checklists Help? - Caren Kresse, Open Source Automation Development Lab (OSADL) eGMake Yourself Useful: How to be an Effective (Non-Profit) Board Member - Deborah Bryant, Red HatThree Cs to an Open Source Program Office - Justin Rackliffe, Fidelity InvestmentsLessons Learned from Starting an Open Source Based Compliance Verification Program - Wenjing Chu, Futurewei Technologies, Inc.Anti-Marketing Marketing: How to Build Authentic Evangelism Programs for Open Source Projects - Ben Cotton, Red Hat; Jen Gray, Adobe; Amanda Katona, VMware; Jennifer Lankford, AnyContext; and Kim McMahon, Cloud Foundry FoundationCompliance and Risk Metrics: Extending CHAOSS - Sean Goggins, University of Missouri; Matt Germonprez, University of Nebraska-Omaha & Kate Stewart, Linux FoundationThe Untold Story Behind Creating an Open Source Program Office - Brian Hsieh, UberIssues of Open Source Compliance Check of Modern Programing Languages and Container Images - Gergely Csatari, NokiaUnderstanding Trademarks in the Context of Open Source - Josh Aas, Internet Security Research Group, Ben Costa & Chris Ridder, Costa & Johnstone LLPShifting Incentives in Open Source Participation - Craig Northway, Qualcomm TechnologiesWhen Production is Someone Else’s Black Box: Safely Developing OSS for the Enterprise - Isobel Redelmeier, LightStepIntro to Setting Up an OSS Compliance Program in Your Organization - Indira Bhatt, Independent Consultant & Gwyn Murray, Matau Legal GroupMeasuring Success in Open Source Software Contribution - How to Stop Counting Lines of Code - Ranny Haiby, SamsungCII Best Practices Badge Project in 2019 - David A. Wheeler, IDAPanel Discussion: Everyday Mentoring, Growth, & Collaboration - Erica Brescia, Bitnami; Vicky Brasseur, Juniper; Rupa Dachere, CodeChix; Erik Riedel, Works Together; and Jaice Singer DuMars, GoogleHow to Leverage Research Universities - Carlos Maltzahn, University of California, Santa CruzManaging an Open Source Project: The Non-Code Work - Jonas Rosland, VMwareHow the Yocto Project Addressed Comcast RDK Scalability Issues - Nicolas Dechesne, Linaro & Khem Raj, ComcastAn Update on Hyperledger & Open Source Blockchain - David Treat, Accenture; Daniela Barbosa & Brian Behlendorf, HyperledgerSentimine: A cregit Plugin to Analyze the Sentiment Behind the Linux Kernel Code - Isabella Vieira Ferreira, Polytechnique MontréalA Novel Way to Efficiently Comply with Licenses - Alexios Zavras, Intel CorporationHow to Manage Open Source at Scale in a Global Enterprise? - Peter Giese, SAPWorking in Foundation-based vs. Company-led Open Source Projects - Ray Paik, GitLab & Stefano Maffulli, ScalityThe FOSSology Project - Latest News and Future Plans - Maximilian Huber, TNG Consulting GmbHSustaining Jenkins Through the CDF - Tracy Miranda, CloudBeesPanel Discussion: Managing Competing Corporate Interests While Driving Coherent Communities - Tom Tofigh, AT&T; Malini Bhandaru, VMware; Prakash Ramchandran, DellEMC & Sujata Tibrewala, IntelR Consortium: Striving to Address Diversity Issues in Open Source - Gabriela de Queiroz, IBM & David Smith, MicrosoftYocto Project: Solving Out of this World Problems! - Lieu Ta, Wind RiverBe Smart, Stay Smart - Open Source for Long-living Products - Urs Gleim, Siemens AGThe Serverless Landscape and Event Driven Futures - Priyanka Sharma, Gitlab & Dee Kumar, The Linux Foundation点击进入网页下载幻灯片（pdf）。KubeCon + CloudNativeCon + Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon + Open Source Summit赞助方案KubeCon + CloudNativeCon + Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon + Open Source Summit购票窗口，立即购票！CNCF邀请你加入最终用户社区 ...

作者：Shuah Khan当Jim Zemlin邀请我来Linux基金会作为Linux研究员，从事指导计划和提高Linux安全性时，我马上答应。我非常高兴能够在Linux基金会，与才华横溢，敬业奉献的人一起工作。这是一个独特而特殊的机会，可以分享我的知识和热情，帮助有抱负的开发者，感受成为世界上最大的开源项目的一部分的喜悦。为Linux内核做贡献，并在开源中工作是我的热情所在。能够成为影响和触动世界上每个人的软件的贡献者是一种荣幸，无论他们是否知道。作为改变我们沟通方式、开展业务、学习和互动的方式的一部分，我和全世界成千上万的开发者一起自豪地分享了作为Linux社区的一分子。我作为Linux内核贡献者的旅程开始是一个有趣的实验，帮助获取Android代码并使其成为核心Linux项目的一部分。我喜欢成为社区一员的经历，并开始寻找更多参与其中的机会。当Greg Kroah-Hartman寻找志愿者来帮助他完成稳定的维护工作时，我报了名。当我继续在内核社区工作时，Greg让我通过维护Linux Kselftest子系统来帮助完成提高Linux内核质量的任务。这使我有机会与在内核的各个部分拥有丰富经验的开发者和维护者合作。它让我保持警惕，为我提供了一个学习和帮助加强Linux内核质量和验证工作的巨大机会。此外，我协助稳定版本维护者，维护USB over IP、cpupower工具，贡献Linux媒体子系统，我在内核技术顾问委员会服务。像许多开源人士一样，我相信分享我的知识和专业。指导开发者是成为维护者和开源好公民的重要工作。任何社区都必须花时间和精力培养新的人才，并培养下一代领导者，以实现持续的成功。我发现Linux内核社区对于像我这样不同背景的人来说是一个非常热情的地方。我有很棒的导师，他们抽出时间帮助我找到我在社区中的位置，并将其作为我的家。我期待与社区分享我的经验，帮助新人克服他们的担忧，如果有的话，帮助他们在这个社区找到一个地方并有宾至如归的感觉。自从加入Linux基金会以来，我一直在努力建立新的指导计划。今天，我很高兴地宣布我们在CommunityBridge上推出新的Linux内核导师计划(Linux Kernel Mentorship Program)，这个平台将为新开发者带来加入和学习社区的机会并同时进行改进。CommunityBridge是一个内核导师可以注册以分享他们的专业知识的地方，并将他们与具有申请工作的基本技能的任何人配对，作为选定的受指导者从我们的社区中学习。CommunityBridge将为个人，提供获得5500美元加上500美元旅行津贴的机会，为期12周的计划，向我们学习并解决诸如查找和修复，将使内核更加稳定和安全的错误等问题。在该计划结束时，受指导者还将与CommunityBridge雇主配对，以便有机会面试一些技术领域的知名公司。重要的是，为了改善我们社区的多样性，Linux基金会将在今年4月开始的夏季环节为来自不同背景的前5名学员提供全额资助。更重要的是，Linux基金会将以一兑一的方式进行匹配捐赠，以支持在CommunityBridge平台上托管的所有项目中的前100名来自不同背景的学员。简而言之，我们可以改进内核代码，将新人带入我们的社区，并为来自不同背景的有抱负的开发者找到工作机会，所有这些都在CommunityBridge上一同发生。我想邀请学员今天就通过申请CommunityBridge的计划，与专家作为指导和导师开始你的开源之旅。我敦促社区合作伙伴尽早捐赠给Linux内核指导计划，以确保Linux Kernel项目的LF匹配捐赠。请与我一起努力使Linux内核变得强大、多样和安全。对于内核以外的重要开源项目，我鼓励你利用CommunityBridge来改善你的社区。KubeCon + CloudNativeCon + Open Source Summit大会日期：会议日程通告日期：2019 年 4 月 10 日会议活动举办日期：2019 年 6 月 24 至 26 日KubeCon + CloudNativeCon + Open Source Summit赞助方案KubeCon + CloudNativeCon + Open Source Summit多元化奖学金现正接受申请KubeCon + CloudNativeCon和Open Source Summit即将首次合体落地中国KubeCon + CloudNativeCon + Open Source Summit购票窗口，立即购票！CNCF邀请你加入最终用户社区

众所周知，去年6月微软以75亿美元的大手笔收购了GitHub；10月份，以Elastic之名进行交易的数据搜索软件初创公司Elasticsearch在美国上市，估值50亿美金。这说明开源和商业并不是完全对立的。当我第一次接触到Inforbight数据库（准确来说是Inforbright存储引擎）时，对它的肤浅认识则是，它是一个与MySQL集成的开源数据仓库，可作为MySQL的一个存储引擎来使用，由于采用列式存储原理，存储数据量大，查询性能高，然后能正常地使用它，仅此而已。直到有一次，同步一批复杂数据文件Load data时碰到了“ERROR 2 (HY000) at line 1: Wrong data or column definition”问题，尝试了应该正常应该能解决问题的各种解决方案后仍无果（可能是版本不同）。因为我们采用的是社区版Inforbright，即ICE，仅支持“LOAD DATA INFILE”的方式导入数据，不支持INSERT、UPDATE、DELETE“。然而我注意到，相对于Inforbright企业版，社区版除了不支持INSERT、UPDATE、DELETE这些操作之外，连load命令的语义也不够丰富：“only supports variable length text formatted load files”，比较之下，其中的道理就很明显了：如同其他产品一样的策略，免费版提供基本功能，付费版提供更多更好的服务。其实，在开源的世界也是如此。随着开源社区以及开源文化的不断进化、发展，开源和商业并不是一对不可调和的矛盾，就如果开源之父Richard Stallman说的那样，free并不代表“免费”，而是自由之意（如自由分发、使用以及持续优化）。在开源的世界里，软件开发工程师的工作种别慢慢出现了细致的分化：研究（开发）与使用（二次开发）。研究：社区或志愿者进行研究活动，发布研究成果-源代码。使用：商业公司根据公开的源代码进行二次开发，将源代码转变为软件产品、服务，从而获利。即开源和商业完全可以很和谐地融合在一起，前者实现知识共享的最大化，后者实现“学以致用”的最大化。目前，开源软件的模式可谓丰富多样，总结下来大概有以下几点：软件开源，但与之配套使用的硬件收费。经典案例：IBM、SUM、HP等传统硬件厂商。知识免费，但由此衍生出来的书籍（培训）收费。经典案例：开源软件出版商O’Reilly公司。程序免费，但部署程序或提供服务（技术or咨询）收费。经典案例：JBoss，类似中间件、ERP和SCM等企业级信息系统，免费提供其源代码，以提供收费的技术和服务盈利。社区版免费，企业版收费。经典案例：Redhat，第一家20亿美元的开源软件公司。如前文中的Inforbright也采用的是这种盈利模式。一种市场策略，如微软宣布部分地开源office源码。正如，所有的东西最终都会被商业收编，开源也不例外。这是一种折中或妥协，也是必然发展的一种趋势。当然这并不是一件坏事，商业可以促进软件的更广泛的传播和更大程度上的优化。REFERENCEShttps://news.microsoft.com/20…http://techgenix.com/elastic-...https://www.cnbeta.com/articl...http://www.lupaworld.com/arti…

作者简介蓝寅，开源分布式中间件DBLE项目负责人；持续专注于数据库方面的技术, 始终在一线从事开发；对数据复制，读写分离，分库分表的有深入的理解与实践。问题起因：用benchmarksql_for_mysql对原生MyCat-1.6.1和DBLE-2.17.07版做性能测试对比，发现DBLE性能只到原生版MyCat的70%左右。问题分析过程：分析过程主要有以下内容：包括现象，收集数据，分析猜测原因，验证猜测的方式来进行。开源分布式中间件DBLE： 社区官网，获取DBLE快速入门指南及最新资讯： https://opensource.actionsky.com GitHub主页，查看官方文档： https://github.com/actiontech… 社区技术交流群，迅速获取官方支持： QQ群：6696631131.分析瓶颈1.1 先对两者进行一个CPU占用的堆栈分析通过对CPU火焰图的比较，发现DBLE用在纯排序上的CPU占用在15%以上，而MyCat在排序上没有看到明显的CPU占用。（ 复盘时的思考：这里有明显的可疑之处，应当及早观察两者是否公平）1.2 首先猜测可能的原因a.由于MyCat对以下这条用例实现有bug：具体方式是直接原句下发SQL到节点，收到各个节点的结果后直接做加法；而DBLE则是改写为select distinct s_i_id 收集全部结果集，然后在中间件做去重和统计的工作。所以两者在这个case上的对比是不公平的。b.排序本身算法选择的问题1.3 对猜测原因的验证a.去除有bug的case，并未看到性能有提升，而且考虑这条用例在所有用例出现的概率只有4%，涉及到的数据也不多，所以应该不是性能问题的主因。b.去除有排序的case，看到两者性能接近，确定是排序的问题。2.猜测原因2.1 猜测一：源码实现原因2.1.1 猜测描述梳理DBLE源码排序逻辑的实现细节，是多路归并的排序，理论上是最优选择。实际上具体的实现上有可优化的空间，如下图， N个数的K路排序的初始化值理论最优复杂度是O(N),而这里变成了O（NlogK2) 。2.1.2 验证猜测为了快速将排序的因素排除，将cmp函数直接返回1再次做测试。结果提升了10%的性能，所以虽然cmp是有性能问题，但导致性能如此大还有其他原因。（复盘：新版本已优化此处10%的性能差异）2.2 猜测二：回到排序SQL查看B-SQL源码，有3个排序SQL，其中有2个排序SQL的排序列不在select 项中，这本来应该引发MyCat的bug的，但我们在返回集和抓包中都没有发现。再仔细阅读源码，原来B-SQL通过hard code的方式使得压力永远跑不到这两个代码路径上，这样我们又排除了2个干扰因素，问题集中到剩下的那个排序上了。将排序除去，64数据量，64并发，DBLE的性能是MyCat的96%。证明确实和排序有关。3.分析多并发压力排序性能的原因3.1 猜测排序算法在特殊场景下的适用性3.1.1 猜测描述由于MyCat排序采用的是timsort， 时间复杂度的可能最优是O(n)。而DBLE的多路归并排序在B-SQL这个场景下时间复杂度最差情况是O（n*(k-1)).猜测timSort排序在B-SQL多并发场景下可能会优于多路归并。3.1.2 验证猜测用B-SQL压测并统计函数调用次数。结论：在B-SQL场景下:两者平均每个排序调用的cmp函数的次数并没有发生明显的异化每个排序cmp次数虽然没有大的差异，但总的调用次数却相差很大,DBLE大约是MyCat的5倍4. 分析DBLE排序时cmp函数次数调用多的原因问题集中在了为什么DBLE会有更多次的比较函数调用。4.1 验证压力下发的SQL是否与cmp函数调用相符是否下发的SQL就不公平4.1.1收集数据用抓包的方式分别抓取B-SQL发给MyCat和DBLE的包，结果发现 DBLE的所有SQL中排序这条SQL的发生次数是MyCat的10倍左右。再次用yourkit查看调用次数和CPU分布验证，发现调用次数确实符合抓包的结论，CPU分布也是DBLE分了大量的时间用于排序，而MyCat对排序的分配几乎可以忽略。这也与最一开始的火焰图结论一样。用wireshark分析DBLE抓包结果，发现某些连接执行一段时间之后大量的重复出现排序+delete的query请求直到压力结束，举例如下图。4.1.2 分析原因分析B-SQL源码这里发现只有delete的数据为0才会引发死循环。4.1.3 验证测试在引发死循环的原因找到之前，先修改代码验证测试。无论result是否是0都设置newOrderRemoved=true使得B-SQL跳出死循环。验证测试，DBLE性能终于符合预期，变为MyCat的105%。至此，B-SQL有排序引发DBLE性能下降的原因找到了，某种场景下B-SQL对DBLE执行delete，影响行数为0，导致此时会有死循环，发送了大量排序请求，严重降低了DBLE性能，并且并发压力越大越容易出现，但也有一定几率不会触发。5.分析哪种场景下delete行数为05.1隔离级别测试因为对隔离级别并不熟悉，花了很长时间才想到原因，在MySQL上做了一个实验：也就是说，在并发情况下确实有可能有死循环出现。5.2 分析为什么只有在DBLE上有这个问题而在MyCat上没有这个问题原因是DBLE和MyCat的默认隔离级别都是REPEATED_READ，但MyCat的实现有bug，除非客户端显式使用set语句，MyCat后端连接使用的隔离级别都是下属结点上的默认隔离级别；而DBLE会在获取后端连接后同步上下文，使得session级别的隔离级别和DBLE配置相同。而后端的四个结点中除了1台是REPEATED_READ，其他三个结点都是READ_COMMITTED。这样同样的并发条件，DBLE100%会触发，而MyCat只有25%的概率触发。5.3 验证测试将DBLE上的配置添加<property name=“txIsolation”>2</property>（默认是3）与默认做对比:性能比是1:0.75.符合期望，性能原因全部找到。6. 吐槽最后吐槽一下B-SQL，找了官方的B-SQL4.1版和5.0版，4.1版并未对此情况做任何改进，仍有可能陷入死循环影响测试。而5.0的对应代码处有这么一段注释，不知道PGSQL是否这里真的会触发异常，但MySQL并不会触发异常，仍有可能陷入死循环。7.性能原因回顾1.cmp函数时候初始化值的问题，影响部分性能，非主要性能瓶颈，新版本已改进。2.同时触发了MyCat和B-SQL的两个bug，导致测试的性能数据负负得正；Mycat bug：配置的隔离级别不生效问题B-SQL bug：RR隔离级别下，delete死循环问题需要将MySQL结点都改为READ_COMMITED,再将配置改为<property name=“txIsolation”>2</property>，避开上述的bug。8.收获1.测试环境的搭建无论是配置参数还是各个节点的状态都要同步，保证公平。2.性能分析工具的使用。3.性能测试可能一次的结果具有偶然性，需要多次验证。4.当有矛盾的结论时候，可能就快接近问题的真相了，需要持续关注。开源分布式中间件DBLE社区官网： https://opensource.actionsky….GitHub主页： https://github.com/actiontech…技术交流群：669663113开源数据传输中间件DTLE社区官网： https://opensource.actionsky….GitHub主页： https://github.com/actiontech…技术交流群：852990221

本文转载自公众号「AI前线」。策划编辑｜Natalie作者｜Kevin Xu译者｜无明编辑｜DebraAI 前线导读：中国科技公司是典型的早期采用者——不是因为赶时髦，而是确实有必要这么做。“中国式规模”让中国的互联网经济成为了高质量软件（特别是基础设施软件）工程的成长沃土，这在开源技术上得到了充分体现。国内开发者和企业向各大开源基金会贡献了越来越多的开源项目，而我们对国外的开源项目也产生了越来越大的影响。本文来自 PingCAP 全球战略和运营总经理 Kevin Xu，AI 前线经授权翻译。我的 87 岁的祖母住在沈阳郊区的一所老房子里。虽然她年岁已高，但却很有技术悟性。平常她会用三个 App 进行网购：在京东上买书，在拼多多上买水果，在淘宝上买其他东西（衬衫、围巾、洗涤剂、数独板）。这三个 App 刚好是由中国电商市场的三巨头开发的，其规模远远超出了千禧一代（1980 至 1994 年出生的人群）和 Z 世代（1995 至 2009 年出生的人群）的受众总和。正是这种“中国式规模”让中国的互联网经济成为高质量软件（特别是基础设施软件）工程的成长沃土。购物节狂欢电子商务是中国互联网经济增长最快的垂直领域之一，同时也带动了数字支付和物流配送的发展。基础设施技术在这一领域经受了最为残酷的考验。“双十一”是最为典型的案例，这是由阿里巴巴提出的一个网购节日，每年的 11 月 11 日，淘宝和天猫都会如期庆祝这个节日。2017 年双十一总销售额为 253 亿美元，2018 年增长到了 308 亿美元。中国第二大电子商务平台京东也有自己的年中购物节，即“618”，这是一个为期 18 天的促销活动，截止 6 月 18 日，这天刚好是京东的成立纪念日。2017 年，618 的总销售额为 176 亿美元，2018 年增长到了 284 亿美元。美国亚马逊的年中购物节 Prime Day 在 2018 年和 2017 年分别创造了 41.9 亿美元和 24.1 亿美元的销售额。美国感恩节购物季在 2018 年和 2017 年的销售额分别为 178 亿美元和 196.2 亿美元。对于工程师来说，有趣的不是令人瞠目结舌的销售数据，而是如何构建可以应对这些工作负载的基础设施。2017 年，阿里巴巴公布了双十一期间系统的高峰吞吐量：每秒 25.6 万笔交易和每秒 4200 万次查询。不难想象，在这些促销活动期间，肯定会不可避免地出现大量的事务、查询、数据一致性问题、实时分析容量和其他难以想象的边缘情况。除了这些公司，所有其他想要搭上这些促销活动顺风车的电子商务公司、所有为用户在线购物提供电子支付解决方案的银行，以及所有的物流中心和仓储中心——他们都需要有好的基础设施技术来应对新的工作负载和流量增长。由于这种增长速度，以及由此产生的竞争压力，中国科技公司在采用新技术方面具有相当强的风险承受能力。一家公司找到合适的产品市场，然后在不到两个月的时间内采用未经证实但很有前景的新技术为高速增长的流量提供服务，这种事情并非闻所未闻。京东在 2016 年初开始采用 Kubernetes，当时离谷歌开源 Kubernetes 还不到一年的时间，因为他们必须解决可伸缩性问题，而 OpenStack 没能帮他们实现这一目标。(京东现在拥有全球最大的 Kubernetes 集群，运行在 2 万台裸机上)更大的规模，更大的责任中国科技公司是典型的早期采用者——不是因为赶时髦，而是确实有必要这么做。中国拥有世界上最多的互联网用户（8 亿，并且还在增加当中），他们的规模（以及规模所带来的不可预知的行为）足够大，大到足以促使这些科技公司认真对待每一项技术。从这些公司生存下来的技术会变得更强大、更有弹性，也更值得被用在其他地方。很多行为是不可能在构建模式下进行预测或测试的。你该如何通过 Paxos 或 Raft 来模拟系统达到 100 倍查询峰值时的网络流量？当一件商品、一首歌或一段视频突然变得像病毒一样迅速传播，而所有用户都在试图访问它们，而更糟糕的是，有价值的广告收入取决于系统不能崩溃，在这种情况下，你该如何处理数据热点问题？当数据增长率为每天数 TB 时，应该如何扩展存储容量?所有这些情况，在很多中国科技公司中时有发生。他们正在迅速地寻找新的解决方案，以迎接这些挑战——这为考验这些创新技术提供了一片沃土。“中国式规模”已经催生了一些由中国原创的基础设施技术。去年，云原生计算基金会（CNCF）接受了其中的三个项目：Harbor、TiKV 和 DragonFly。它们的架构和用例都在之前的一篇文章（https://softwareengineeringdaily.com/2018/12/09/chinese-open-source-software/）中做了很好的介绍。在 CNCF 生态系统之外，还有其他一些值得关注的项目。OceanBase由蚂蚁金服开发的分布式关系数据库，最初用于支持支付宝。支付宝在中国已经无处不在。此后，OceanBase 逐渐成为阿里巴巴所有关键电子商务平台（如淘宝和天猫）的核心交易数据库。它也是一个独立的产品，南京银行就是它的用户之一。2014 年以来，它经历了五次双十一的考验。可惜的是，它是一个闭源产品，在中国以外没有得到广泛采用，所以与其架构、设计或工程方面相关的英文信息并不多。TiDB一个开源的、兼容 MySQL 的 NewSQL 分布式数据库，由 PingCAP 于 2015 年创建。它采用了分层架构，SQL 处理层（左边的 TiDB 集群）和可水平伸缩的存储层（中间的 TiKV 集群）被分隔开来。（注：TiKV 也由 PingCAP 发起，但现在由 CNCF 托管）。这个设计灵感来自于谷歌的 Spanner 和基于 Spanner 构建的 F1 项目。PD（Placement Driver）集群保存元数据，提供一些负载均衡支持，并提供时间戳（作为系统事务模型的一部分）。TiSpark 集群是一个可选组件，用户可以直接基于保存在 TiKV 中的数据运行 Spark 作业。目前，中国已经有几百家公司在生产环境中部署了 TiDB，如摩拜、北京银行和爱奇艺。国外也有一些大型互联网公司使用了 TiDB，如 Shopee 和 BookMyShow。注：PingCAP 现已提供 TiDB 的企业版和云服务，同时也在维护开源社区版本。Apache Kylin一个快速的 OLAP（在线分析处理）引擎，最初由 eBay 中国团队开发，在 2014 年贡献给 Apache 基金会，并在 2015 年底成为顶级项目。Kylin 主要被用在 Hadoop 生态系统中，为数百亿行数据的分析查询带来可观的速度提升。用户先定义数据模型，然后利用 Hadoop 的分布式特性并行运行多个 MapReduce 作业，用以预构建必要的多维模型（也称为“MOLAP”）。最后，Kylin 将预先计算的模型存储在 HBase 中，供用户查询。它还使用 Zookeeper 来协调和管理这个过程的不同部分。作为大数据分析引擎，Kylin 集成了 Tableau、MicroStrategy、Excel 等流行的 BI 工具。它还提供了一个 RESTful API，方便与第三方应用程序连接。除了 eBay，它还在 OPPO、百度、中国太平洋保险等公司经受过实战考验，三星和摩根大通也是它的用户。Apache Skywalking一个相对较新的开源应用程序性能监监控（APM）工具，用于在基于容器的环境中监控微服务。2017 年底，它成为 Apache 基金会的孵化器项目。Skywalking 通过服务网格从微服务中提取指标，并利用 Jaeger 等流行工具来跟踪信息，并可以查询和分析这些指标和信息，还可以使用团队开发的 UI 进行可视化。它还提供了一个可插拔的存储接口，借助这个接口，可以将信息保存在一些流行的数据库中，比如 Elasticsearch、MySQL 和 TiDB。尽管这个项目成立还不到两年，但中国的一些大型公司已经在使用它，如华为、小米和贝壳。中国之外除了本土技术，国外的一些技术也有了“中国式规模”的味道。京东是 Prometheus、Vitesse、Jenkins 和 GitLab 等技术的用户，百度是 CockroachDB（另一个受 Spanner 启发的开源数据库，类似于 TiDB）的用户。Alluxio，一个分布式文件系统统一层，可以以内存速度运行（源自加州大学伯克利分校 AMPLab 的一个名为 Tachyon 的研究项目），也在百度、中国联通和滴滴出行等企业中得到采用。中国公司不仅在大规模采用这些技术，有时候甚至直接收购它们。开源数据流平台 Apache Flink 由柏林技术大学于 2009 年创建，作为 Stratosphere 研究项目的一部分。阿里巴巴最终收购了由 Flink 创始人创办的 dataArtisan（该公司的目的是商业化 Flink）。有价值的权衡?作为工程师，我们知道没有什么技术是绝对的，它们总是存在权衡。我们总是在吞吐量和延迟、数据一致性和响应时间、新特性和系统稳定性之间做出权衡。我们很少能鱼与熊掌兼得，我们也不相信把自己标榜得太高的技术。市场的选择也是如此。在中国互联网经济大环境中，有一些问题一定要考虑到，特别是信息审查方面的问题。比如，对侵犯知识产权行为的法律追索仍然不太可靠，有关企业使用个人数据的监管尚处于初级阶段。但如果你是一名开发者，正在寻找一些稳定可靠的技术（已经“面面俱到”的技术），那么那些已经在中国互联网环境中经受过实战考验的技术将是安全的选择。如果你的团队正在构建下一个大项目，尤其是在基础设施层面，那么把这个项目交给中国的几家科技巨头公司，将会为项目带来跨越式的发展。另外，你们的努力很可能也会为我的祖母带来更快乐的生活！英文原文：https://softwareengineeringdaily.com/2019/02/26/china-scale-the-new-sandbox-to-battle-test-innovative-technology/作者介绍:Kevin Xu 是 PingCAP 全球战略和运营总经理。他在斯坦福大学完成计算机科学与法律专业的学习。主要关注分布式系统、云原生技术、自然语言处理和开源。 ...

文章来源：爱可生云数据库作者：余朝飞DBLE项目介绍DBLE官方网站：https://opensource.actionsky.com可以详细了解DBLE的背景和应用场景，本文不涉及到的细节都可在官方文档获得更细节都信息；对于刚了解到同学，可以以本文为快速入门基础DBLE官方项目：https://github.com/actiontech…如对源码有兴趣或者需要定制的功能的可以通过源码编译DBLE下载地址：https://github.com/actiontech…建议下载最新的releases版本，下载tar压缩包即可，如有源码编译需求的，可以下载源码包DBLE的主要配置文件上一篇"DBLE Schema.xml 配置解析"详细介绍了DBLE之中关于Scema.xml的配置，本篇文章将继续为大家讲解一下DBLE中Rule.xml文件的配置。DBLE的配置文件都在conf目录里面，常用的几个配置文件如下：文件说明server.xmlDBLE server相关参数定义，包括dble性能，定时任务，端口，用户配置等；本文主要涉及到访问用户的配置schema.xmlDBLE具体分片定义，规定table和schema以及dataNode之间的关系，指定每个表格使用哪种类型的分片方法，定义每个dataNode的连接信息等rule.xmlDBLE实际用到的分片算法的配置rule.xml配置解析其中rule.xml是日常配置分片算法的时候最常用到的配置文件，我们通过思维导图的方式给大家整理了DBLE的rule.xml的配置，需要注意的是思维导图不能代替看文档，导图只能起着概括归纳的作用，详细的细节还请参考官方文档。rule.xml举例从分片的数据在各个数据节点分布来看，分片可分为连续分片和离散分片,连续分片就是将一定范围内的数据全部分布在某一DataNode, 离散分布则是通过hash取模等方法将数据打散较为均匀地分布在各个DataNode。分片连续分片离散分片优点并发访问能力有限，扩容迁移代价小并发访问能力增强 范围条件查询性能提升缺点存在数据热点的可能性，并发访问能力受限于单一或少量DataNode .数据扩容比较困难，需要对整体数据做重新分布。举例date,numberrangehash, stringhash, patternrange注：hash，patternrange分片方式如果配置分片区间足够宽的话也是可以当做连续分片的。以下我以PatternRange算法为例，讲解一下如何配置该拆分算法，比如当前有一张表tasK_log已经有1000万的数据，这张表又因为需要和其他表进行关联查询，单表太大进行关联时异常缓慢，因此我们需要对这张表做拆分， 将这张表分别放在三个分片上，dn1,dn2,dn3。schema.xml中的配置如下 <table name=“tasK_log” dataNode=“dn1,dn2,dn3” rule=“three_node_range” />rule.xml中配置如下:<?xml version=“1.0”?><!DOCTYPE dble:rule SYSTEM “rule.dtd”><dble:rule xmlns:dble=“http://dble.cloud/"> <tableRule name=“three_node_range”> <rule> <columns>id</columns> <algorithm>three_node_range</algorithm> </rule> </tableRule> <function name=“three_node_range” class=“PatternRange”> <property name=“mapFile”>partition.txt</property> <property name=“patternValue”>1024</property> <property name=“defaultNode”>0</property> </function></dble:rule>mapfile partition.txt定义如下：[root@localhost ~]# cat partition.txt 0-255=0256-511=1512-1024=2查找路由时，将id字段与patternValue取模，即计算M = id % patternValue,如果M在0-255之间，在数据落在dn1分片。如果M在256-511之间，在数据落在dn2分片。如果M在512-1024之间，则数据落在dn3分片。如果都匹配不上，则落在默认节点defaultNode dn1分片(理论上在这个例子中是不可能匹配不上的)关于每一种拆分算法的详细介绍请参加官方文档介绍。总结rule.xml定义实际用到的拆分算法以及该拆分算法对应到的逻辑库使用使用算法，熟悉各种拆分算法的详细配置及其适用场景，才方便我们在众多数据拆分场景选择并配置合适的拆分规则，同时这也是适用分库分表中间件的第一步，并且实地演示了一个小小的拆分例子，使用到了patternrange算法。将表的详细拆分规则写在配置中，这是一种很"傻"的方式，但是这也是万不得已的一种选择，如果不通过配置文件的方式告诉中间件这些信息，那么中间件就无从得知底层具体的数据分布情况，也就达不到我们最终想要分库分表的目的了。

阿里作为一家技术公司，一举一动牵动业界的发展。2013年，阿里搞出去ioe的概念，旨在消除对他人的依赖。而现在，它自己却通过变卖开源产品，绑架企业，充当了类似ioe的角色。相比较一些国际知名的开源软件，阿里的开源软件文档不全、功能阉割、失久未修，很没诚意。它唯一目的就是让你买它的阿里云服务，哦，即使买了服务也有无限的内购。阿里的开源软件还是不要玩，大多是为了商业宣传。小公司或者个人的软件能通过长期的口碑，逐渐将优势显现；而影响力比较高的阿里之流可能会为了短期利益混淆视听，将坏的唱成好的。怎么正确使用阿里开源的软件呢，我这里有个建议。像一些工具包之类的，比如fastjson、druid等，可以放心使用，因为替换容易；像一些低频使用的，工作量堆彻的软件如DataX，也可以酌情使用；而像一些企业级的应用，可能要持续数年的重要技术栈，比如dubbo，就要小心一些，说不定啥时候就撂挑子不干了。当然也是有分别的。像RocketMQ因为进了apache，就比较照顾自己的面子。即使这样，社区版的和内部的版本之间，也有不少的差别。通常都是雷声大雨点小，天天开分享会。发布个初始版本以后，就太监了。所以，使用阿里的软件要慎重。为了消除项目长期的技术风险，对此公司开源的东西，要充满戒备。评估标准最后更新时间通常，源码都会放在github。可以看一下代码的最新更新时间。当然这个更新不是随便的，更新一个readme文档不算更新，要看是不是重要功能和bug修复。当然更新时间还和项目的新旧有关，比较新的项目参考价值小。你要随便用了，需要承担风险。比如tddl，7年前的代码了。你要用了就上当了。这样的项目很多。现在有人提tddl和cobar，这是得有多落伍。Star数star数其实是大家的关注度，并不是判定的唯一标准。2018年，阿里的员工有7.4w。如果有十分之一的员工star了他们公司的项目，就有7千多星。再加上每年离职的流动人口，这个数值就呵呵了。即使这样，大多数项目关注度并不高。star数量能够看出项目的欢迎程度，但大型公司的项目要打折。项目来源有些项目确实是公司内部孵化出来的，比如Canal等。但大多数是拿了别的公司的开源软件，修了一些bug，做了一点改进，然后加个前缀当作自己的作品。这类开源软件不想着通过正规途径去反馈社区，也不能肩负起后续的维护工作。一般都是为了非常私人的或者团队的目的，要么生命周期很短，要么转向闭源。它通过发展分支的方式，滥用影响力，干扰原开源软件的发展，合法但是不道德的。典型的如AliSQL、AliRedis、以及最新的spring-cloud-alibaba，搞到最后只能适应自己的云环境，最终为商业化服务。而开发者真正能从中得到的成本和便捷，非常有限。文档如果只有简单的几行文档，加上铺天盖地的开发者大会宣传，不用也罢。当然如果你有大把的时间也可以搞一下。讲原理的文档是最优的；讲用法的文档是有诚意的；啥都没有是正常的；讲成就和吹牛皮的文档是最次的，大家要有分辨力。点到为止，是大公司的特色。否则教会了徒弟饿死了师父，开源的目的就变了。pin功能github的pin功能是将自己觉得好的项目置顶到最上面，我们看下阿里置顶的是啥。有5个是工具类项目，放心大胆用，因为这是口碑的来源；还有一个是容器引擎，反正用的人也少。如数家珍啊。社区口碑issues的数量和心跳图的比率。还可以在各社区问一下大家的看法。像这种，持续有心跳的项目，用着还是比较放心的。版权声明这个就算了吧，阿里不遵守，我们也很少有人遵守。后端项目替换推荐工具类的就不提了，推荐用或者能用的有：canal、fastjson、druid、rocketmq。其他的，就算了吧。像什么核心中间件比如数据库中间件、文件服务器、缓存等，是不给你用的。比较有争议的dubboRPC框架。文档和社区不错。可惜，躺尸后又诈尸的项目，你不确定什么时候又躺尸了。已经透支了很多公司的信任。替代品：Spring Cloud，功能即丰富又稳定。AliSQL内部有用和牛逼的东西，不见得社区会买账。可能用的更多的还是RDS，小公司是可以玩的，上点规模应该想着怎么去掉它。替代品：MariaDB、MySQLspring-cloud-alibaba微服务框架，二次封装。建议使用原生Spring Cloud。End最近开源界有点小风波，先是Redis、Neo4j更改了软件协议，然后Kafka紧随其后，最近连Mongodb也忍不住将协议改成了SSPL。佛性程序员可能心理不平衡了，不想再免费付出了。阿里对开发者的这些伤害，可能是无意的，因为亚马逊也在干同样的事情。但开源阉割版产品，铺天盖地的正向宣传，是有意为之。有了阿里云这个造钱的机器，很多东西都会变味。不要觉得开源软件是免费的，和商业公司讲情怀，还嫩了点。这么做也无可厚非，但是当了婊子还想立牌坊，未免就太无耻了些。

在工作学习之余，你可能会萌生做一个开源项目的想法。一方面将自己的好代码分享出去帮助更多开发者，另一方面也希望在开源社区中得到反馈和成长。如果项目能获得很多的关注那更是锦上添花，高 Star 不仅是衡量开源项目可靠程度的一个重要依据，这样项目维护者的 Github 也能在招聘中让公司提前了解候选人的开源贡献、技术热情和编程习惯等，获得面试官的加分。那么，开源项目怎么才能获得更多的 Star 数呢？这里通过总结我这段时间维护 Day.js 项目的过程中的一些经验教训，来说说如何改进和推广你的开源项目。瞄准用户痛点开源社区的内容包罗万象，整理收藏的 Markdown 笔记、 框架全家桶的搭建、炫酷的动画效果以及各种工具库、框架等都是很好的开源方向，但是考虑到项目的功能、受众、开发语言等等因素，不同类型的项目实现起来的难度和被社区接受的程度也千差万别。但如果项目能瞄准开发者的痛点，提供优秀的解决方案，就有获得更多关注的可能。一个人的精力始终是有限的，只有更多的人加入进来，使用、反馈、迭代和推广，才能形成开源项目的良性循环。比如我在工作中发现 Moment.js 虽然能很方便地处理日期和时间但这个库打包体积太大了，而要想迁移到社区其他几个轻量的时间库又会增加新的学习成本和迁移工作量。所以开发 Day.js 的目标就是做一个和 Moment.js 一样 API 设计，一样功能，更加轻量的时间日期库。选择开源协议相较与项目本身的代码和文档等，开源协议可能是一个容易被忽视的细节。开源协议是软件的授权许可，表述了用户获得你开源的代码后拥有的权利和义务。我在初期推广时就犯了个错误，没意识到开源协议的重要性，也没有给项目添加任何协议。在版权意识相对更强的英文社区宣传时就遇到了很大的阻力和各种质疑，他们觉得这样的项目是不专业的，也不敢去轻易尝试，就这样白白错失了一部分初始用户。关于怎么去选择一个适合项目的开源协议，可以参考这个网站 Choose License。如果你希望项目可以尽可能被广泛地推广、使用和传播，就可以考虑选择一个分发自由度比较高的开源协议。规范提交记录使用一个规范的 Git 提交记录是很有必要的，这不仅让多人开发中的参与者能更好地了解项目的迭代历史和进程，也能在出现问题时快速定位，找到问题代码的提交记录。同时我们还可以使用工具根据提交记录自动生成更新说明 (CHANGELOG)，方便用户了解每次更新的具体内容，也免去了项目维护者手动更新的痛苦。目前前端社区中使用较多的 Git Commit 提交规范是 Angular 规范 (Git Commit Message Conventions )，Commit 的格式包含 Header、Body、Footer 三个部分：<type>(<scope>): <subject><body><footer>但如果每次提交代码的 Commit Message 都需要我们按照上述格式来录入的话还是一件又累又容易忘记的苦差事。推荐两个工具来辅助我们的操作：使用 commitizen 进行交互式的 Commit 填写，如下图所示，只需要按照提示选择更新的 type 和填写必要的信息，就能自动生成符合规范的提交记录；使用 @semantic-release/changelog 来根据 Commit 中 type 自动增量生成 CHANGELOG；语义化版本号每个社区都有自己的版本号规范，千万不能因为是自己的开源项目就随心所欲地填写版本号，不然可能会给使用者带来不必要的麻(彩)烦(蛋)。在 NPM 生态圈中绝大部分包都是使用语义化版本号 (Semantic Versioning)，即版本号为 a.b.c 的形式，其中 a 是大版本号，b 是次版本号，c 是修订号。如果开源项目有按上文所述规范地提交 Commit ，就可以使用 semantic-release 来实现全自动更新版本号和发布，这个工具会判断 Commit Message 的不同，fix 增加修订号，feat 增加次版本号，而包含 BREAKING CHANGE 的提交增加大版本号。推广和分析酒香也怕巷子深，再精美的项目，如果作者自身没什么知名度，又没有太多推广的话，这个项目很有可能就被淹没在众多开源项目之中了。除了在众所周知的国内开发社区推广之外，希望大家也不要忽视了国外的社区和论坛。要知道虽然中文开发者数量越来越多，但也只占到全球开发者的一部分，为了获得更多关注，我们有必要把开源项目国际化，来帮助更多的开发者。而英语是软件开发者们的通用语言，翻译一份英文版的 README 就是走向国际化的第一步。在推广 Day.js 的过程中，我会在 Twitter 大佬们吐槽 Date 函数、 Moment.js 库的推文下，介绍我的项目的特点，希望他们可以尝试一下（但要有礼貌，广告别太硬）。社区红人的一个 Star 或一条支持的推文就能依靠社交网络快速传播，给项目带来巨大的流量和很高的关注度。在每次的重大功能更新或集中推广之后，我们要通过项目的 Pull request, Issue, Star, Download Count 等数据的变化来了解推广效果和用户的满意度。前端工程师都知道，比起一堆数字，可视化的数据图表可以帮助我们更好地理解数据。如 npmjs.com 展示下载量变化的折线图，可以分析项目被使用和被依赖的情况。bestofjs.org 展示了项目 Star 数变化的日历色块图，格子越深说明增量越快。下图深色的小块就是项目几次比较成功的推广，而有些推广并没有带来很大的增长就需要总结经验并改善方法了。开始做一个开源项目并不难，要勇敢地迈出自己的第一步。但是持续维护开源项目并不是一件很容易坚持下来的事，我们需要找到自己维护项目的动力，给用户提供必要的支持，收集用户的反馈，不断完善项目，进而形成一个完整的产品闭环来推动项目的不断迭代更新。当然能做到这些， Star 数量的多少已经不是那么重要了，我们丰富了开源社区的内容，帮助了更多的开发者，也从开源的经历中得到了视野的拓展，能力的提升，这才更有价值的收获。P.S. 如果你热爱前端，热爱开源，欢迎加入我们团队，这里有网红开源 UI 库 Element，承接了公司 98% 前端项目的发布系统，比 jsdeliver 更好用的静态资源管理平台和更多有意思的项目等着你。请联系 kun.zhu@ele.me ，饿了么大前端有你更精彩。 ...

转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。本文由葡萄城技术团队于博客园原创并首发昨天，在国外民众还在欢度圣诞期间，开发者社区却对 Antd 开发团队发起了连番的炮轰。一觉醒来，他们发现由自己参与设计的、公司内网、办事系统等网页上，有一些按钮的上面多了一团白色的“积雪”，在白背景下，看着有点像是被“咬掉”了一块似的，不仅如此，将鼠标指向变化了的按钮时，原本设定好的文字说明也统一变成了“Ho ho ho”，这是“圣诞老人”标志性的笑声。原因是库中暗藏了一个未事先告知的圣诞彩蛋、而且也没法手动禁用，导致许多项目方遭遇了客户投诉。从评论来看，网友们的情绪普遍比较激动，不少人表示“老板问我按钮为什么被狗啃了”、“今天的工作就是给客户们解释我们代码没有被注入”。软件彩蛋的本意是指常用软件当中隐藏了一些小东东，这些小东东我们称之为复活节彩蛋。复活节彩蛋的内容包含的很广，从单纯的列出开发人员名单到各类小游戏都有，但它们都有一个共同的特点就是用户是可控的。我们常用的软件如Windows、Office以及我们用来上网的浏览器IE中都有这样的彩蛋。但号称专注于企业级应用的一个UI库，那么不严肃。敢问哪个老板喜欢这样的“惊喜”？随意调侃节日的UI库，除了这次的圣诞，后面还会不会有元旦、春节、劳动节？事件出现后，在代码托管网站 GitHub 和社交媒体上，开发者们及吃瓜群众表现出了一边倒批评的态度 ——“我留意到按钮组件的上方出现了一块雪花？这是圣诞节彩蛋吧？为什么不经过开发者的允许就擅自加上了？”有人说虽然自己觉的很可爱，但这样的彩蛋不可取有说自己是XX委的，没丢工作还得多亏了自己的小姨子有人说自己看到彩蛋很惊吓，有种失控的感觉也有吐槽英文拼写错误的… AntD这套框架是由支付宝母公司蚂蚁金服设计团队制作的一套开源的前端框架。据蚂蚁金服设计团队今年9月的数据，Ant Design 1.0在发布之后的8个月中，就已经在 GitHub 上收获了 11686 个”星标“。这意味着至少有这些数量的程序员关注，并使用了AntD到自己的项目上。就是这一得到业界广泛关注和使用的基础组件，突然在毫无预警，也没有功能开关的前提下，给所有使用者的按钮控件”下了一场雪“——而且还是在”生产环境“中，不出意外，今天这个彩蛋自己就能自行消失，如果仍然没有消失，请查看作者提供的修复方式：https://github.com/ant-design…AntD是一个采用了 MIT 许可协议的开源项目，所以开发者并不需要为受到损失的开发者承担任何责任。既然做开源项目放到 GitHub 上就是赚个吆喝，不为盈利，也不承担法律责任，那么很显然，“信任”就是一个项目最为金贵的核心价值。开源软件的每一个细节，都暴露在“阳光之下”，只要有心，人们都可以发现。所以理论上任何一点想拿开源产品“图谋不轨”的做法都不会得逞。但是，今天这起事件的发生，又反映了什么？为什么理应有人看到并监督的问题，却安静地躺了两个月都没人发现？开源社区持续出现类似的问题，信任危机也许也只是刚刚开始。后续也许会再次发生此类事件，开发者除了需要认真检查每次的更新外，自己造轮子也可以杜绝这样的问题，但幸亏在这个时代葡萄城有着众多真正出色的企业级商业软件，相信选择使用葡萄城成熟的商业软件：SpreadJS、WijmoJS 是一个更不错的选择，毕竟一家优秀的厂商会为开发者承担所有可能出现的风险这点很重要。最后，让我们祝福他们做的更好。【作者推荐】前端开发工具包 - WijmoJSWijmoJS 前端开发工具包由多款高效、灵活的纯前端控件组成，全面支持 Angular、React、Vue、TypeScript、Knockout 和 Ionic 框架，用于快速搭建企业级桌面/移动 Web 应用程序。WijmoJS 可灵活应对客户需求变化，缩短新项目研发周期，高效处理海量用户数据，提升产品核心竞争力。借助葡萄城深厚的技术底蕴，WijmoJS 为各领域用户提供更稳定、更高效的前端开发工具，帮助中国招商银行、微软、思科、特斯拉、富士通等知名企业快速搭建其 Web 应用程序。WijmoJS 凭借先进的触控设计、全面的框架支持、顶级的控件性能、零依赖的产品特性和易用、轻松的操作体验，全面满足前端开发所需，已成为构建企业 Web 应用程序最高效的纯前端开发工具包。

今天的 AntDesign 圣诞节彩蛋事件确实炸开了锅，加彩蛋的初衷是好的，只是这次玩过了火。在开源软件中，加彩蛋是一种乐趣，并不为奇，同为知名 UI 组件库的 iView 项目，也经常在 文档 中埋藏很多彩蛋，不过仅仅是在 文档 中，组件库中是没有的。本来就来介绍下我们在开源项目中是怎样埋彩蛋的。全民彩蛋计划为庆祝 iView 两周岁生日，以及 3.0 版本的发布，我们在 18 年 7 月 28 日更新后， iView 文档 中放置了三枚彩蛋，它们埋藏在不同的页面里，可能是一段隐藏的代码，或是一段需要破解的密码等等。当然，找到三枚彩蛋，你并不能继承 iView 作者的遗产！彩蛋可以到 iView 开发者社区 兑换大量的 IO 币，IO 币可以换取各种礼物。这个活动已经进行了 5 个月，已经有两名聪明的小伙伴成功找到了前两枚彩蛋，第一枚的位置是在 Collapse 折叠面板 页面的最后一个示例中：https://www.iviewui.com/compo… 显示方法就是点击倒数第二个示例“简洁模式”中的第二个面板斯蒂夫·盖瑞·沃兹尼亚克，然后双击内容最后的 19840124，页面中就会弹出一个提示：19840124 是一个日期，也就是 1984 年 1 月 24 日，这一天，苹果发布了麦金塔电脑（Macintosh），对于苹果来说具有历史性的意义。第一枚彩蛋就是为了纪念这个事件。第二枚彩蛋的位置在 Circle 进度环 页面的第二个示例总：https://www.iviewui.com/compo… 显示方法是点击“+号”按钮，当圆环到达 100% 后，再点击两次“+号”，页面中就会弹出一个提示：这串字符是用 base 64 编码过的，解码后，就是第二枚彩蛋的正确答案了：ToyStory-PixarPixar 就是皮克斯动画工作室，是由苹果前 CEO 乔布斯被“赶出家门”后收购的，ToyStory 就是《玩具总动员》，是皮克斯制作的一部计算机动画长片和第一部剧场影片，给无数小朋友带来了欢乐。第二枚彩蛋就是纪念它的。第三枚彩蛋至今（2018-12-25）仍未被找到，聪明的你要赶快行动哦！第三枚彩蛋与前两枚同样与苹果公司有关，这是因为 iView 的作者非常喜欢 Apple 和乔布斯！弹幕彩蛋在文档中埋彩蛋并不是 iView 的第一次活动了，在 16 年的 7 月 28 日（iView 一周岁），iView 文档首页增加了发弹幕的功能，你发的弹幕，同一时间打开文档首页的用户都可以实时看到。一开始，大家玩的都很愉快，比如说 PHP 是世界上最好的语言 的，还有要妹子微信的，这很程序员：再到后来，就被玩坏了，因为没有加验证，聪明的程序员各种 XSS 手段都用上了，于是画风就变成了这样：这是一次典型的 XSS 攻击案例，哈哈！活动持续了 1 星期，总共发布了 10 万多条弹幕，大家玩的很开心。节日彩蛋逢年过节，iView 首页都会装饰，比如万圣节、圣诞节、春节。主要会美化一下 Logo 和改变首页背景图，比如今天的圣诞节，iView 的 Logo 是这样的：比如 2018 年的春节：春节有两个细节，一个是首页会放烟花（因为是截图，看不到动画），另一个是右上角有一个“福”字，当时可以支持支付宝的扫福活动。2017 年的万圣节：2017 年的圣诞节：如果恰巧在一些特殊的时间节点发布了新版本，iView 在更新日志里也会做一个小彩蛋，或者说是纪念。比如 2018-03-14，这一天是史蒂芬·霍金离开这个世界的日子，我们在更新日志中和当天的文档首页也有纪念（首页为黑白色，现在无法找到当时的截图了），下面是更新日志：后记埋藏彩蛋是一个很有意思和意义的事情，许多游戏、电影、开源软件都有彩蛋。它们爱自己的用户，爱这个世界，希望给人们带来欢喜。iView 也会不断带来新的彩蛋，给用户带来惊喜，当然，它只会出现在文档中，源码是不用担心的！ ...

项目背景CAT（Central Application Tracking），是美团点评基于 Java 开发的一套开源的分布式实时监控系统。美团点评基础架构部希望在基础存储、高性能通信、大规模在线访问、服务治理、实时监控、容器化及集群智能调度等领域提供业界领先的、统一的解决方案，CAT 目前在美团点评的产品定位是应用层的统一监控组件，在中间件（RPC、数据库、缓存、MQ 等）框架中得到广泛应用，为各业务线提供系统的性能指标、健康状况、实时告警等服务。本文会对 CAT 的客户端、性能等做详细深入的介绍，前不久我们也发过一篇 CAT 相关的文章，里面详细介绍了 CAT 客户端和服务端的设计思路，欲知更多细节，欢迎阅读《深度剖析开源分布式监控CAT》产品价值减少故障发现时间降低故障定位成本辅助应用程序优化技术优势实时处理：信息的价值会随时间锐减，尤其是在事故处理过程中全量数据：全量采集指标数据，便于深度分析故障案例高可用：故障的还原与问题定位，需要高可用监控来支撑故障容忍：故障不影响业务正常运转、对业务透明高吞吐：海量监控数据的收集，需要高吞吐能力做保证可扩展：支持分布式、跨 IDC 部署，横向扩展的监控系统使用现状目前，CAT 已经覆盖了美团点评的外卖、酒旅、出行、金融等核心业务线，几乎已经接入美团点评的所有核心应用，并在生产环境中大规模地得到使用。2016 年初至今，CAT 接入的应用增加了400%，机器数增加了 900%，每天处理的消息总量高达 3200 亿，存储消息量近 400TB，高峰期集群 QPS 达 650万/秒。面对流量的成倍增长，CAT 在通信、计算、存储方面都遇到了前所未有的挑战。整个系统架构也经历了一系列的升级和改造，包括消息采样聚合、消息存储、业务多维度指标监控、统一告警等等，项目最终稳定落地。为公司未来几年内业务流量的稳定增长，打下了坚定的基石。经过 7 年的持续建设，CAT 也在不断发展，我们也希望更好的回馈社区，将 CAT 提供的服务惠及更多的外部公司。我们今年将对开源版本进行较大的迭代与更新，未来也会持续把公司内部一些比较好的实践推广出去，欢迎大家跟我们一起共建这个开源社区。新版特性CAT 3.0.0 Release Notes多语言客户端随着业务的不断发展，很多产品和应用需要使用不同的语言，CAT 多语言客户端需求日益增多，除 Java 客户端外，目前提供了 C/C++、Python、Node.js、Golang 客户端，基本覆盖了主流的开发语言。对于多语言客户端，核心设计目标是利用 C 客户端提供核心 API 接口作为底层基石，封装其他语言 SDK。目前支持的主流语言使用指南：JavaC/C++PythonNode.jsGolang性能提升消息采样聚合消息采样聚合在客户端应对大流量时起到了至关重要的作用，当采样命中或者内存队列已满时都会经过采样聚合上报。采样聚合是对消息树拆分归类，利用本地内存做分类统计，将聚合之后的数据进行上报，减少客户端的消息量以及降低网络开销。通信协议优化CAT 客户端与服务端通信协议由自定义文本协议升级为自定义二进制协议，在大规模数据实时处理场景下性能提升显著。目前服务端同时支持两种版本的通信协议，向下兼容旧版客户端。测试环境：CentOS 6.5，4C8G 虚拟机测试结果：新版相比旧版，序列化耗时降低约 3 倍消息文件存储新版消息文件存储进行了重新设计，解决旧版本的文件存储索引、数据文件节点过多以及随机 IO 恶化的问题。新版消息文件存储为了同时兼顾读写性能，引入了二级索引存储方案，对同一个应用的 IP 节点进行合并，并且保证一定的顺序存储。下图是索引结构的最小单元，每个索引文件由若干个最小单元组成。每个单元分为 4×1024 个桶，第一个桶作为我们的一级索引 Header，存储 IP、消息序列号与分桶的映射信息。剩余 4×1024 - 1 个桶作为二级索引，存储消息的地址。新版消息文件存储文件节点数与应用数量成正比，有效减少随机 IO，消息实时存储的性能提升显著。以下为美团点评内部 CAT 线上环境单机消息存储的数据对比：未来规划技术栈升级拥抱主流技术栈，降低学习和开发成本，使用开源社区主流技术工具（Spring、Mybatis等），建设下一代开源产品。产品体验对产品、交互进行全新设计，提升用户体验。开源社区建设产品官网建设、组织技术交流。更多语言 SDK关于开源https://github.com/dianping/catCAT 自 2011 年开源以来，Github 收获 5900+ star，2400+ forks，被 100+ 公司企业使用，其中不乏携程、陆金所、猎聘网、平安等业内知名公司。在每年全球 Qcon 大会、全球架构与运维技术峰会等都有持续的技术输出，受到行业内认可，越来越多的企业伙伴加入了 CAT 的开源建设工作，为 CAT 的成长贡献了巨大的力量。美团点评基础架构部负责人黄斌强表示，在过去四年中，美团点评在架构中间件领域有比较多的积累沉淀，很多系统服务都经历过大规模线上业务实际运营的检验。我们在使用业界较多开源产品的同时，也希望能把积累的技术开源出去，一方面是回馈社区，贡献给整个行业生态；另一方面，让更多感兴趣的开发工程师也能参与进来，共同加速系统软件的升级与创新。所以，像 CAT 这样的优秀项目，我们将陆续开源输出并长期持续运营，保证开源软件本身的成熟度、支撑度与社区的活跃度，也欢迎大家给我们提出更多的宝贵意见和建议。结语这是一场没有终点的长跑，我们整个 CAT 项目组将长期有耐心地不断前行。愿同行的朋友积极参与我们，关注我们，共同打造一款企业级高可用、高可靠的分布式监控中间件产品，共同描绘 CAT 的新未来！这次开源仅仅是一个新的起点，如果你对 CAT 新版本有一些看法以及建议，欢迎联系我们：cat@dianping.com or Github issues招聘信息美团点评基础架构团队诚招 Java 高级、资深技术专家，Base北京、上海。我们是集团致力于研发公司级、业界领先基础架构组件的核心团队，涵盖分布式监控、服务治理、高性能通信、消息中间件、基础存储、容器化、集群调度等技术领域。欢迎有兴趣的同学投送简历到 yong.you@dianping.com。 ...

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~本文由腾讯云视频发表于云+社区专栏关注公众号“腾讯云视频”，一键获取 技术干货 | 优惠活动 | 视频方案欢迎来到吃鸡战场很生气！！！我才刚落地，就因游戏界面糊了一下，阻止了我捡枪的步伐，就被不知道从哪蹿出来的家伙给打死了！！！瞬间落地成盒！！！我很愤怒，于是找了游戏部门的同事吐槽了一番，得到的回答是：画质的问题归你们部门，劳烦你自行进行处理！为了能让自己有个愉快的游戏体验感，于是乎，深陷于研发高清画质的工作中……经过前期的了解，得知当前游戏直播行业1080P、>=45FPS、码率6-10mbps已成为游戏主播上行的标配，各视频平台用户对视频源清晰度观看体验要求越来越高，CDN带宽成本占视频APP平台成本比例大头。如何降低带宽成本压力是各视频平台降成本最重要的措施，其中视频降码率是现阶段主要措施有，主要措施如下：算法升级AV1/H.265/VP9/H.264等，AV1刚定稿AOM编码性能相比其它3家100倍以上差距，由于核心成员有Google/Amazon/Cisco/Netflix等这些大佬以及定位对web的友好性，AV1 3月刚完成V1.0的定稿以及ffmpeg4.0的支持，可以预见的是，后面硬件支持友好后，Netflix、Youtube都将是第一批AV1的使用者，H.265其复杂专利结构导致的较高许可费用，创立之初也未充分考虑到网页播放的友好性，更致命的是复杂的算法让解码端异常吃力，VP9开源、WEB兼容性也好、解码复杂度低，除Apple和技术原因外可能的理由之一就是业内也不太愿意让这么重要一个国际标准被一个独立的公司所控制。 现在视频平台主流编码算法还是以H.264为主普通转码短视频和直播平台、视频网站对视频分源、超清、高清、流畅等不同档位，基本都是一些按分辨率和码率要求强制压缩转码，效果不理想都是以省码率为目标没有考虑用户观看体验极速窄带高清腾讯云极速高清、窄带高清以及netflix的动态编码都是基于场景、清晰度、分辨率、码率、帧率、编码算法、播放策略等目标在不降低甚至增强源视频画质体验的基础上降低视频码率视频源和普通转码存在的问题视频源和普通转码主要存在的质量问题有：转码失真、低分辨率模糊、镜头抖动、噪声大、低码率锯齿块等极速高清是如何解决这些问题视频智能分类 把视频分成游戏、秀场、体育、户外、动漫、美食、影视剧等十几个大类几十个小类场景，通过画面特征比较，明显场景类如游戏、足球、蓝球、动漫等场景，纯CNN网络模型准确率98%以上，电视剧、户外运动、美食、旅游等画面特征比较分散，帧间运动变化比较大的场景CNN结合RNN+LSTM做时域+空域分析，准确率85%左右编码参数 通过视频场景分类实时识别（特殊直播场景识别延时大概有10秒-60秒左右），根据场景识别结果，不同场景配置不同最优编码参数， 根据视频源码率、帧率、分辨率、纹理和运动变化幅度等情况以及综合机器负载和画质效果选择最优编码模板参数前置处理 根据不同场景分类、客户对视频画质的不同要求，以及结合视频源画面纹理和实时运动检测结果进行锐化、软模糊、反交错、去块、降噪、色阶补偿、降帧等前置处理动态优化 不同的视频类别，同一个视频里的不同段，应用完全不一样的编码参数；“不同的参数”的概念包括但不限于：IBP帧类型、量化参数QP、分辨率等，支持编码参数按帧实时更新生效码率控制 不管是标准H.264/JVT-G012 码率控制算法还是x264的码率控制算法在运动变化切换比较明显的场景下预编一次得到率失真理论凸曲线都是尽可能接近最优失真曲线，国内CDN带宽基本都是按95计费法，CDN带宽采样点是5分种的均值，对于这种运动场景实时检测切换比较明显的场景帧我们在x264码率控制的基础上会综合帧时序信息做一些补偿因子和画质控制，画质VMAF得分会有3-5分以上的提高如上图极速高清在VMAF得分相同情况下码率控制更低更精准。detail reduce ☟针对h264视频编码格式，设计了一种在视频残差的频域上消除噪声的算法。该算法结合了当前编码宏块的残差大小，宏块的QP值，历史的频域值等，并根据不同场景选择匹配的video denoise模板，自适应地进行宏块级的视频处理，能够以极低的CPU消耗对噪声宏块进行优化，同时保留清晰宏块的完整性ROI处理 ☟SIFT+差分图像+运动目标图像检测或用户指定(如台标、水印)关注ROI区域，对该区域的宏块编码进行强化(放大/缩小量化步长)、锐化、色阶补偿等处理，如央视世界杯就要求对台标和字幕区域画质和亮度增强VMAF评分 ☟VMAF是Video Multimethod Assessment Fusion的缩写netflix 开源的视频主观感受质量评估算法，看名字这就是一种多方法融合的算法，主要使用了3种指标：visual quality fidelity（VIF）、detail loss measure（DLM）、temporal information（TI）。其中VIF和DLM是空间域的也即一帧画面之内的特征，TI是时间域的也即多帧画面之间相关性的特征。这些特性之间融合计算总分的过程使用了训练好的SVM来预测基本原理流程图从我们评估测试对比效果看VMAF得分和人眼主观感受画面质量很接近，基本能反应用户对画质的主观感受，当然VMAF在一些主要评估特性功能上还有很多功能不完全支持以及评估时要手动严格帧对齐也比较费精力，netflix训练模型主要是在明亮的室内通过电视观看1080p视频时的质量评估。不过手机上的模型也在做了效果不是非常理想github地址：https://github.com/Netflix/vmaf极速高清主要基于VMAF的得分效果优化相关编码参数和算法调整效果效果对比上图是极速高清与普通转码和xx云窄带高清转码同码率下效果对比，总体我们测试效果和客户反馈对比效果看同码率下我们VMAF分比竞品和普通转码高10以分以上，同画质VAMF得分下我们码率最大能降低30%左右另注： PSNR和SSIM三大直接问题：◆ 它只能衡量其与原图的差异也即相对质量，不能计算绝对质量◆◆ 孤立地计算每一帧，无法利用视频中相邻帧的相关性和运动信息◆◆◆ PSNR/SSIM值的计算方法过于straight-forward，结果跟人眼的主观感受并不总能匹配客户反馈极速高清现在应用主要客户有：熊猫、斗鱼、龙珠、虎牙、火猫、企鹅电竞、CCTV、新英体育等客户。且极速高清服务也可进行私有化部署，全程支撑cctv.com世界杯期间赛事直播今天天气好晴朗，处处好风光，好风光……皇天不负有心人，自从有了极速高清的应用，在游戏中分分钟吃鸡，瞬间成为部门的吃鸡高手，还有不少小迷妹让我带着吃鸡呢，迎来了人生的巅峰，哈哈哈哈哈哈问答请问小程序即时通讯如何接入发送消息？相关阅读IM即时通讯实现原理iOS 即时通讯 + 仿微信聊天框架 + 源码开发一款即时通讯App，从这几步开始 【每日课程推荐】机器学习实战！快速入门在线广告业务及CTR相应知识

背景目前，开源社区和业界内已经存在一些 iOS 导航栏转场的解决方案，但对于历史包袱沉重的美团 App 而言，这些解决方案并不完美。有的方案不能满足复杂的页面跳转场景，有的方案迁移成本较大，为此我们提出了一套解决方案并开发了相应的转场库，目前该转场库已经成为美团点评多个 App 的基础组件之一。在美团 App 开发的早期，涉及到导航栏样式改变的需求时，经常会遇到转场效果不佳或者与预期样式不符的“小问题”。在业务体量较小的情况下，为了满足快速的业务迭代，通常会使用硬编码的方式来解决这一类“小问题”。但随着美团 App 业务的高速发展，这种硬编码的方式遇到了以下的挑战：业务模块的不断增加，导致使用硬编码方式编写的代码维护成本增加，代码质量迅速下降。大型 App 的路由系统使得页面间的跳转变得更加自由和灵活，也使得导航栏相关的问题激增，不但增加了问题的排查难度，还降低了整体的开发效率。App 中的导航栏属于各个业务方的公用资源，由于缺乏相应的约束机制和最佳实践，导致业务方之间的代码耦合程度不断增加。从各个角度来看，硬编码的方式已经不能很好的解决此类问题，美团 App 需要一个更加合理、更加持久、更加简单易行的解决方案来处理导航栏转场问题。本文将从导航栏的概念入手，通过讲解转场过程中的状态管理、转换时机和样式变化等内容，引出了在大型应用中导航栏转场的三种常见解决方案，并对美团点评的解决方案进行剖析。重新认识导航栏导航栏里的 MVC在 iOS 系统中， 苹果公司不仅建议开发者遵循 MVC 开发框架，在它们的代码里也可以看到 MVC 的影子，导航栏组件的构成就是一个类似 MVC 的结构，让我们先看看下面这张图：在这张图里，我们可以将 UINavigationController 看做是 C，UINavigationBar 看做是 V，而 UIViewController 和 UINavigationItem 组成的 Stack 可以看做是 M。这里要说明的是，每个 UIViewController 都有一个属于自己的 UINavigationItem，也就是说它们是一一对应的。UINavigationController 通过驱动 Stack 中的 UIViewController 的变化来实现 View 层级的变化，也就是 UINavigationBar 的改变。而 UINavigationBar 样式的数据就存储在 UIViewController 的 UINavigationItem 中。这也就是为什么我们在代码里只要设置 self.navigationItem 的相关属性就可以改变 UINavigationBar 的样式。很多时候，国内的开发者会将 UINavigationBar 和 UINavigationController 混在一起叫导航栏，这样的做法不仅增加了开发者之间的沟通成本，也容易导致误解。毕竟它们是两个完全不一样的东西。所以本文为了更好的阐明问题，会采用英文区分不同的概念，当需要描述笼统的导航栏概念时，会使用导航栏组件一词。通过这一节的回顾，我们应该明确了 NavigationItem、ViewController、NavigationBar 和 NavigationController 在 MVC 框架下的角色。下面我们会重新梳理一下导航栏的生命周期和各个相关方法的调用顺序。导航栏组件的生命周期大家可以通过下图获得更为直观的感受，进而了解到导航栏组件在 push 过程中各个方法的调用顺序。值得注意的地方有两点：第一个是 UINavigationController 作为 UINavigationBar 的代理，在没有特殊需求的情况下，不应该修改其代理方法，这里是通过符号断点获取它们的调用顺序。如果我们创建了一个自定义的导航栏组件系统，它的调用顺序可能会与此不同。第二个是用虚线圈起来的方法，它们也有可能不被调用，这与 ViewController 里的布局代码相关，假设跳转到新页面后，新旧页面中的控件位置会发生变化，或者由于数据改变驱动了控件之间的约束关系发生变化，这就会带来新一轮的布局，进而触发 viewWillLayoutSubview 和 viewDidLayoutSubview 这两个方法。当然，具体的调用顺序会与业务代码紧密相关，如果我们发现顺序有所不同，也不必惊慌。下面这张图展示了导航栏在 pop 过程中各个方法的调用顺序：除了上面说到的两点，pop 过程中还需要注意一点，那就是从 B 返回到 A 的过程中，A 视图控制器的 viewDidLoad 方法并不会被调用。关于这个问题，只要提醒一下，大多数人都会反应过来是为什么。不过在实际开发过程中，总会有人忘记这一点。通过这两个图，我们已经基本了解了导航栏组件的生命周期和相关方法的调用顺序，这也是后面章节的理论基础。导航栏组件的改变与革新导航栏组件在 iOS 11 发布时，获得了重大更新，这个更新可不是增加了一个大标题样式（Large Title Display Mode）那么简单，需要注意的地方大概有两点：导航栏全面支持 Auto Layout 且 NavigationBar 的层级发生了明显的改变，关于这一点可以阅读 UIBarButtonItem 在 iOS 11 上的改变及应对方案 。由于引进了 Safe Area 等概念，topLayoutGuide 和 bottomLayoutGuide 等属性会逐渐废弃，虽然变化不大，但如果我们的导航栏在转场过程中总是出现视图上下移动的现象，不妨从这个方面思考一下，如果想深究可以查看 WWDC 2017 Session 412。导航栏组件到底怎么了？经常有人说 iOS 的原生导航栏组件不好使用，抱怨主要集中在导航栏组件的状态管理和控件的布局问题上。控件的布局问题随着 iOS 11 的到来已经变得相对容易处理了不少，但导航栏组件的状态管理仍然让开发者头疼不已。可能已经有朋友在思考导航栏组件的状态管理到底是什么东西？不要着急，下面的章节就会做相关的介绍。导航栏的状态管理虽然导航栏组件的 push 和 pop 动画给人一种每次操作后都会创建一遍导航栏组件的错觉，但实际上这些 ViewController 都是由一个 NavigationController 所管理，所以你看到的 NavigationBar 是唯一的。在 NavigationController 的 Stack 存储结构下，每当 Stack 中的 ViewController 修改了导航栏，势必会影响其他 ViewController 展示的效果。例如下图所示的场景，如果 NavigationBar 原先的颜色是绿色，但之后进入 Stack 里的 ViewController 将 NavigationBar 颜色修改为紫色后，在此之后 push 的 ViewController 会从默认的绿色变为紫色，直到有新的 ViewController 修改导航栏颜色才会发生变化。虽然在 push 过程中，NavigationBar 的变化听起来合情合理，但如果你在 NavigationBar 为绿色的 ViewController 里设置不当的话，那么当你 pop 回这个 ViewController 时，NavigationBar 可就不一定是绿色了，它还会保持为紫色的状态。通过这个例子，我们大概会意识到在导航栏里的 Stack 中，每个 ViewController 都可以永久的影响导航栏样式，这种全局性的变化要求我们在实际开发中必须坚持“谁修改，谁复原”的原则，否则就会造成导航栏状态的混乱。这不仅仅是样式上的混乱，在一些极端状况下，还有可能会引起 Stack 混乱，进而造成 Crash 的情况。导航栏样式转换的时机我们刚才提到了“谁修改，谁复原”的原则，但何时修改，何时复原呢？对于那些存储在 Stack 中的 ViewController 而言，它其实就是在不断的经历 appear 和 disappear 的过程，结合 ViewController 的生命周期来看，viewWillAppear: 和 viewWillDisappear: 是两个完美的时间节点，但很多人却对这两个方法的调用存在疑惑。苹果公司在它的 API 文档中专门用了一段文字来解答大家的疑惑，这段文字的标题为《Handling View-Related Notifications》，在这里我们直接引用原文：When the visibility of its views changes, a view controller automatically calls its own methods so that subclasses can respond to the change. Use a method like viewWillAppear: to prepare your views to appear onscreen, and use the viewWillDisappear: to save changes or other state information. Use other methods to make appropriate changes.Figure 1 shows the possible visible states for a view controller’s views and the state transitions that can occur. Not all ‘will’ callback methods are paired with only a ‘did’ callback method. You need to ensure that if you start a process in a ‘will’ callback method, you end the process in both the corresponding ‘did’ and the opposite ‘will’ callback method.这里很好的解释了所有的 will 系列方法和 did 系列方法的对应关系，同时也给我们吃了一个定心丸，那就是在 appearing 和 disappearing 状态之间会由 will 系列方法进行衔接，避免了状态中断。这对于连续 push 或者连续 pop 的情况是及其重要的，否则我们无法做到 “谁修改，谁复原”的原则。通常来说，如果只是一个简单的导航栏样式变化，我们的代码结构大体会如下所示：- (void)viewWillAppear:(BOOL)animated{ [super viewWillAppear:animated]; // MARK: change the navigationbar style }- (void)viewWillDisappear:(BOOL)animated{ [super viewWillDisappear:animated]; // MARK: restore the navigationbar style}现在，我们明确了修改时机，接下来要明确的就是导航栏的样式会进行怎样的变化。导航栏的样式变化对于不同 ViewController 之间的导航栏样式变化，大多可以总结为两种情况：导航栏的显示与否导航栏的颜色变化导航栏的显示与否对于显示与否的问题，可以在上一节提到的两个方法里调用 setNavigationBarHidden:animated: 方法，这里需要提醒的有两点：在导航栏转场的过程中，不要天真的以为 setNavigationBarHidden: 和 setNavigationBarHidden:animated: 的效果是一样的，直接使用 setNavigationBarHidden: 会造成导航栏转场过程中的闪现、背景错乱等问题，这一现象在使用手势驱动转场的场景中十分常见，所以正确的方式是使用带有 animated 参数的 API。在 push 和 pop 的方法里也会带有 animated 参数，尽量保证与 setNavigationBarHidden:animated: 中的 animated 参数一致。导航栏的颜色变化颜色变化的问题就稍微复杂一些，在 iOS 7 后，导航栏增加了 translucent 效果，这使得导航栏背景色的变化出现了两种情况：translucent 属性值为 YES 的前提下，更改导航栏的背景色。translucent 属性值为 NO 的前提下，更改导航栏的背景色。对于第一种情况，我们需要调用 UINavigationBar 的 setBackgroundColor: 方法。对于第二种情况我们需要调用 UINavigationBar 的 setBackgroundImage:forBarMetrics: 方法。对于第二种情况，这里有三点需要提示：在设置透明效果时，我们通常可以直接设置一个 [UIImage new] 创建的对象，无须创建一个颜色为透明色的图片。在使用 setBackgroundImage:forBarMetrics: 方法的过程中，如果图像里存在 alpha 值小于 1.0 的像素点，则 translucent 的值为 YES，反之为 NO。也就是说，如果我们真的想让导航栏变成纯色且没有 translucent 效果，请保证所有像素点的 alpha 值等于 1。如果设置了一个完全不透明的图片且强行将 NavigationBar 的 translucent 属性设置为 YES 的话，系统会自动修正这个图片并为它添加一个透明度，用于模拟 translucent 效果。如果我们使用了一个带有透明效果的图片且导航栏的 translucent 效果为 NO 的话，那么系统会在这个带有透明效果的图片背后，添加一个不透明的纯色图片用于整体效果的合成。这个纯色图片的颜色取决于 barStyle 属性，当属性为 UIBarStyleBlack 时为黑色，当属性为 UIBarStyleDefault 时为白色，如果我们设置了 barTintColor，则以设置的颜色为基准。分清楚 transparent，translucent，opaque，alpha 和 opacity 也挺重要在刚接触导航栏 API 时，许多人经常会把文档里的这些英文词搞混，也不太明白带有这些词的变量为什么有的是布尔型，有的是浮点型，总之一切都让人很困惑。在这里将做了一个总结，这对于理解 Apple 的 API 设计原则十分有帮助。transparent， translucent， opaque 三个词经常会用在一起，它用于描述物体的透光强度，为了让大家更好的理解这三个词，这里做了三个比喻：transparent 是指透明，就好比我们可以透过一面干净的玻璃清楚的看到外面的风景。translucent 是指半透明，就好比我们可以透过一面有点磨砂效果的塑料墙看外面的风景，不能说看不见，但我们肯定看不清。opaque 是指不透明，就好比我们透过一个堵石墙是看不见任何外面的东西，眼前看到的只有这面墙。这三个词更多的是用来表述一种状态，不需要量化，所以这与这三个词相关的属性，一般都是 BOOL 类型。alpha 和 opacity 经常会在一起使用，它要表示的就是透明度，在 Web 端这两个属性有着明显的区别。在 Web 端里，opacity 是设定整个元素的透明值，而 alpha 一般是放在颜色设置里面，所以我们可以做到对特定对元素的某个属性设定 alpha，比如背景、边框、文字等。div { width: 100px; height: 100px; background: rgba(0,0,0,0.5); border: 1px solid #000000; opacity: 0.5;}这一概念同样适用于 iOS 里的概念，比如我们可以通过 alpha 通道单独的去设置 backgroudColor、borderColor，它们互不影响，且有着独立的 alpha 通道，我们也可以通过 opacity 统一设置整个 view 的透明度。但与 Web 端不一致的是，iOS 里面的 view 不光拥有独立的 alpha 属性，同时也是基于 CALayer，所以我们可以看到任意 UIView 对象下面都会有一个 layer 的属性，用于表明 CALayer 对象。view 的 alpha 属性与 layer 里面的 opacity 属性是一个相等的关系，需要注意的是 view 上的 alpha 属性是 Web 端并不具备的一个能力，所以笔者认为：在 iOS 中去说 alpha 时，要区分是在说 view 上的属性，还是在说颜色通道里的 alpha。由于这两个词都是在描述程度，所以我们看到它们都是 CGFloat 类型：转场过程中需要注意的问题和细节说完了导航栏的转场时机和转场方式，其实大体上你已经能处理好不同样式间的转换，但还有一些细节需要你去考虑，下面我们来说说其中需要你关注的两点。translucent 属性带来的布局改变translucent 会影响导航栏组件里 ViewController 的 View 布局，这里需要大家理清 5 个 API 的使用场景：edgesForExtendedLayoutextendedLayoutIncluedsOpaqueBarsautomaticallyAdjustScrollViewInsetscontentInsetAdjustmentBehavioradditionalSafeAreaInsets前三个 API 是 iOS 11 之前的 API，它们之间的区别和联系在 Stack Overflow 上有一个比较精彩的回答 - Explaining difference between automaticallyAdjustsScrollViewInsets, extendedLayoutIncludesOpaqueBars, edgesForExtendedLayout in iOS7，我在这里就不做详细阐述，总结一下它的观点就是:如果我们先定义一个 UINavigationController，它里面包含了多个 UIViewController，每个 UIViewController 里面包含一个 UIView 对象：那么 edgesForExtendedLayout 是为了解决 UIViewController 与 UINavigationController 的对齐问题，它会影响 UIViewController 的实际大小，例如 edgesForExtendedLayout 的值为 UIRectEdgeAll 时，UIViewController 会占据整个屏幕的大小。当 UIView 是一个 UIScrollView 类或者子类时，automaticallyAdjustsScrollViewInsets 是为了调整这个 UIScrollView 与 UINavigationController 的对齐问题，这个属性并不会调整 UIViewController 的大小。对于 UIView 是一个 UIScrollView 类或者子类且导航栏的背景色是不透明的状态时，我们会发现使用 edgesForExtendedLayout 来调整 UIViewController 的大小是无效的，这时候你必须使用 extendedLayoutIncludesOpaqueBars 来调整 UIViewController 的大小，可以认为 extendedLayoutIncludesOpaqueBars 是基于 automaticallyAdjustsScrollViewInsets 诞生的，这也是为什么经常会看到这两个 API 会同时使用。这些调整布局的 API 背后是一套基于 topLayoutGuide 和 bottomLayoutGuide 的计算而已，在 iOS 11 后，Apple 提出了 Safe Area 的概念，将原先分裂开来的 topLayoutGuide 和 bottomLayoutGuide 整合到一个统一的 LayoutGuide 中，也就是所谓的 Safe Area，这个改变看起来似乎不是很大，但它的出现确实方便了开发者。如果想对 Safe Area 带来的改变有更全面的认识，十分推荐阅读 Rosberry 的工程师 Evgeny Mikhaylov 在 Medium 上的文章 iOS Safe Area，这篇文章基本涵盖了 iOS 11 中所有与 Safe Area 相关的 API 并给出了真正合理的解释。这里只说一下 contentInsetAdjustmentBehavior 和 additionalSafeAreaInsets 两个 API。对于 contentInsetAdjustmentBehavior 属性而言，它的诞生也意味着 automaticallyAdjustsScrollViewInsets 属性的失效，所以我们在那些已经适配了 iOS 11 的工程里能看到如下类似的代码：if (@available(iOS 11.0, *)) { self.tableView.contentInsetAdjustmentBehavior = UIScrollViewContentInsetAdjustmentNever;} else { self.automaticallyAdjustsScrollViewInsets = NO;}此处的代码片段只是一个示例，并不适用所有的业务场景，这里需要着重说明几个问题：关于 contentInsetAdjustmentBehavior 中的 UIScrollViewContentInsetAdjustmentAutomatic 的说明一直很“模糊”，通过 Evgeny Mikhaylov 的文章，我们可以了解到他在大多数情况下会与 UIScrollViewContentInsetAdjustmentScrollableAxes 一致，当且仅当满足以下所有条件时才会与 UIScrollViewContentInsetAdjustmentAlways 相似：UIScrollView 类型的视图在水平轴方向是可滚动的，垂直轴是不可滚动的。ViewController 视图里的第一个子控件是 UIScrollView 类型的视图。ViewController 是 navigation 或者 tab 类型控制器的子视图控制器。启用 automaticallyAdjustsScrollViewInsets。iOS 11 后，通过 contentInset 属性获取的偏移量与 iOS 10 之前的表现形式并不一致，需要获取 adjustedContentInset 属性才能保证与之前的 contentInset 属性一致，这样的改变需要我们在代码里对不同的版本进行适配。对于 additionalSafeAreaInsets 而言，如果系统提供的这几种行为并不能满足我们的布局要求，开发者还可以考虑使用 additionalSafeAreaInsets 属性做调整，这样的设定使得开发者可以更加灵活，更加自由的调整视图的布局。backIndicator 上的动画苹果提供了许多修改导航栏组件样式的 API，有关于布局的，有关于样式的，也有关于动画的。backIndicatorImage 和 backIndicatorTransitionMaskImage 就是其中的两个 API。backIndicatorImage 和 backIndicatorTransitionMaskImage 操作的是 NavigationBar 里返回按钮的图片，也就是下图红色圆圈所标注的区域。想要成功的自定义返回按钮的图标样式，我们需要同时设置这两个 API ，从字面上来看，它们一个是返回图片本身，另一个是返回图片在转场时用到的 mask 图片，看起来不怎么难，我们写一段代码试试效果：self.navigationController.navigationBar.backIndicatorImage = [UIImage imageNamed:@“backArrow”];self.navigationController.navigationBar.backIndicatorTransitionMaskImage = [UIImage imageNamed:@“backArrowMask”];代码里的图片如下所示：也许大多数人在这里会都认为，mask 图片会遮挡住文字使其在遇到返回按钮右边缘的时候就消失。但实际的运行效果是怎么样子的呢？我们来看一下：在上面的图片中，我们可以看到返回按钮的文字从返回按钮的图片下面穿过并且文字被图片所遮挡，这种动画看起来十分奇怪，这是无法接受的。我们需要做点修改：self.navigationController.navigationBar.backIndicatorImage = [UIImage imageNamed:@“backArrow”];self.navigationController.navigationBar.backIndicatorTransitionMaskImage = [UIImage imageNamed:@“backArrow”];这一次我们将 backIndicatorTransitionMaskImage 改为 indicatorImage 所用的图片。到这里，可能大多数人都会好奇，这代码也能行？让我们看下它实际的效果：在上面的图中，我们看到文字在到达图片的右边缘时就从下方穿过并被完全遮盖住了，这种动画效果虽然比上面好一些，但仍然有改进的空间，不过这里我们先不继续优化了，我们先来讨论一下它们背后的运作原理。iOS 系统会将 indicatorImage 中不透明的颜色绘制成返回按钮的图标， indicatorTransitionMaskImage 与 indicatorImage 的作用不同。indicatorTransitionMaskImage 将自身不透明的区域像 mask 一样作用在 indicatorImage 上，这样就保证了返回按钮中的文字像左移动时，文字只出现在被 mask 的区域，也就是 indicatorTransitionMaskImage 中不透明的区域。掌握了原理，我们来解释下刚才的两种现象：在第一种实现中，我们提供的 indicatorTransitionMaskImage 覆盖了整个返回按钮的图标，所以我们在转场过程中可以清晰的看到返回按钮的文字。在第二种实现中，我们使用 indicatorImage 作为 indicatorTransitionMaskImage，记住文字是只能出现在 indicatorTransitionMaskImage 里不透明的区域，所以显然返回按钮中的文字会在图标的最右边就已经被遮挡住了，因为那片区域是透明的。那么前面提到的进一步优化指的是什么呢？让我们来看一下下面这个示例图，为了更好的区分，我们将 indicatorTransitionMaskImage 用红色进行标注。黑色仍然是 indicatorImage。按照刚才介绍的原理，我们应该可以理解，现在文字只会出现在红色区域，那么它的实际效果是什么样子的呢，我们可以看下图：现在，一个完美的返回动画，诞生啦！此节所用的部分效果图出自 Ray Wenderlich 的文章 UIAppearance Tutorial: Getting Started导航栏的跳转或许可以这么玩儿…前两章的铺垫就是为了这一章的内容，所以现在让我们开始今天的大餐吧。这样真的好么？刚才我们说了两个页面间 NavigationBar 的样式变化需要在各自的 viewWillAppear: 和 viewWillDisappear: 中进行设置。那么问题就来了：这样的设置会带来什么问题呢？试想一下，当我们的页面会跳到不同的地方时，我们是不是要在 viewWillAppear: 和 viewWillDisappear: 方法里面写上一堆的判断呢？如果应用里还有 router 系统的话，那么页面间的跳转将变得更加不可预知，这时候又该如何在 viewWillAppear: 和 viewWillDisappear: 里做判断呢？现在我们的问题就来了，如何让导航栏的转场更加灵活且相互独立呢？常见的解决方案如下所示：重新实现一个类似 UINavigationController 的容器类视图管理器，这个容器类视图管理器做好不同 ViewController 间的导航栏样式转换工作，而每个 ViewController 只需要关心自身的样式即可。将系统原有导航栏的背景设置为透明色，同时在每个 ViewController 上添加一个 View 或者 NavigationBar 来充当我们实际看到的导航栏，每个 ViewController 同样只需要关心自身的样式即可。在转场的过程中隐藏原有的导航栏并添加假的 NavigationBar，当转场结束后删除假的 NavigationBar 并恢复原有的导航栏，这一过程可以通过 Swizzle 的方式完成，而每个 ViewController 只需要关心自身的样式即可。这三种方案各有优劣，我们在网上也可以看到很多关于它们的讨论。例如方案一，虽然看起来工作量大且难度高，但是这个工作一旦完成，我们就会将处理导航栏转场的主动权牢牢抓在手里。但这个方案的一个弊端就是，如果苹果修改了导航栏的整体风格，就好比 iOS 11 的大标题特效，那么工作量就来了。对于方案二而言，虽然看起来简单易用，但这需要一个良好的继承关系，如果整个工程里的继承关系混乱或者是历史包袱比较重，后续的维护就像“打补丁”一样，另外这个方案也需要良好的团队代码规范和完善的技术文档来做辅助。对于方案三而言，它不需要所谓的继承关系，使用起来也相对简单，这对于那些继承关系和历史包袱比较重的工程而言，这一个不错的解决方案，但在解决 Bug 的时候，Swizzle 这种方式无疑会增加解决问题的时间成本和学习成本。我们的解决方案在美团 App 的早期，各个业务方都想充分利用导航栏的能力，但对于导航栏的状态维护缺乏理解与关注，随着业务方的增加和代码量的上升，与导航栏相关的问题逐渐暴露出来，此时我们才意识到这个问题的严重性。大型 App 的导航栏问题就像一个典型的“公地悲剧”问题。在软件行业，公用代码的所有权可以被视作“公地”，因为不注重长期需求而容易遭到消耗。如果开发人员倾向于交付“价值”，而以可维护性和可理解性为代价，那么这个问题就特别普遍了。如果是这种情况，每次代码修改将大大减少其总体质量，最终导致软件的不可维护。所以解决这个问题的核心在于：明确公用代码的所有权，并在开发期施加约束。明确公用代码的所有权，可以理解为将导航栏相关的组件抽离成一个单独的组件，并交由特定的团队维护。而在开发期施加约束，则意味着我们要提供一套完整的解决方案让各个业务方遵守。这一节我们会以美团内部的解决方案为例，讲解如何实现一个流畅的导航栏跳转过程和相关使用方法。设计理念使用者只用关心当前 ViewController 的 NavigationBar 样式，而不用在 push 或者 pop 的时候去处理 NavigationBar 样式。举个例子来说，当从 A 页面 push 到 B 页面的时候，转场库会保存 A 页面的导航栏样式，当 pop 回去后就会还原成以前的样式，因此我们不用考虑 pop 后导航栏样式会改变的情况，同时我们也不必考虑 push 后的情况，因为这个是页面 B 本身需要考虑的。使用方法转场库的使用十分简单，我们不需要 import 任何头文件，因为它在底层通过 Method Swizzling 进行了处理，只需要在使用的时候遵循下面 4 点即可：当需要改变导航栏样式的时候，在视图控制器的 viewDidLoad 或者 viewWillAppear: 方法里去设置导航栏样式。用 setBackgroundImage:forBarMetrics: 方法和 shadowImage 属性去修改导航栏的背景样式。不要在 viewWillDisappear: 里添加针对导航栏样式修改的代码。不要随意修改 translucent 属性，包括隐式的修改和显示的修改。隐式修改是指使用 setBackgroundImage:forBarMetrics: 方法时，如果 image 里的像素点没有 alpha 通道或者 alpha 全部等于 1 会使得 translucent 变为 NO 或者 nil。基本原理以上，我们讲完了设计理念和使用方法，那么我们来看看美团的转场库到底做了什么？从大方向上来看，美团使用的是前面所说的第三种方案，不过它也有一些自己独特的地方，为了更好的让大家理解整个过程，我们设计这样一个场景，从页面 A push 到页面 B，结合之前探讨过的方法调用顺序，我们可以知道几个核心方法的调用顺序大致如下：页面 A 的 pushViewController:animated:页面 B 的 viewDidLoad or viewWillAppear:页面 B 的 viewWillLayoutSubviews页面 B 的 viewDidAppear:在 push 过程的开始，转场库会在页面 A 自身的 view 上添加一个与导航栏一模一样的 NavigationBar 并将真的导航栏隐藏。之后这个假的导航栏会一直存在页面 A 上，用于保留 A 离开时的导航栏样式。等到页面 B 调用 viewDidLoad 或者 viewWillAppear: 的时候，开发者在这里自行设置真的导航栏样式。转场库在这里会对页面布局做一些修正和辅助操作，但不会影响导航栏的样式。等到页面 B 调用 viewWillLayoutSubviews 的时候，转场库会在页面 B 自身的 view 上添加一个与真的导航栏一模一样的 NavigationBar，同时将真的导航栏隐藏。此时不论真的导航栏，还是假的导航栏都已经与 viewDidLoad 或者 viewWillAppear: 里设置的一样的。当然，这一步也可以放在 viewWillAppear: 里并在 dispatch main queue 的下一个 runloop 中处理。等到页面 B 调用 viewDidAppear: 的时候，转场库会将假的导航栏样式设置到真的导航栏中，并将假的导航栏从视图层级中移除，最终将真的导航栏显示出来。为了让大家更好地理解上面的内容，请参考下图：说完了 push 过程，我们再来说一下从页面 B pop 回页面 A 的过程，几个核心方法的调用顺序如下：页面 B 的 popViewControllerAnimated:页面 A 的 viewWillAppear:页面 A 的 viewDidAppear:在 pop 过程的开始，转场库会在页面 B 自身的 view 上添加一个与导航栏一模一样的 NavigationBar 并将真的导航栏隐藏，虽然这个假的导航栏会一直存在于页面 B 上，但它自身会随着页面 B 的 dealloc 而消亡。等到页面 A 调用 viewWillAppear: 的时候，开发者在这里自行设置真的导航栏样式。当然我们也可以不设置，因为这时候页面 A 还持有一个假的导航栏，这里还保留着我们之前在 viewDidLoad 里写的导航栏样式。等到页面 A 调用 viewDidAppear: 的时候，转场库会将假的导航栏样式设置到真的导航栏中，并将假的导航栏从视图层级中移除，最终将真的导航栏显示出来。同样，我们可以参考下面的图来理解上面所说的内容：现在，大家应该对我们美团的解决方案有了一定的认识，但在实际开发过程中，还需要考虑一些布局和适配的问题。最佳实践在维护这套转场方案的时间里，我们总结了一些此类方案的最佳实践。判断导航栏问题的基本准则如果发现导航栏在转场过程中出现了样式错乱，可以遵循以下几点基本原则：检查相应 ViewController 里是否有修改其他 ViewController 导航栏样式的行为，如果有，请做调整。保证所有对导航栏样式变化的操作出现在 viewDidLoad 和 viewWillAppear: 中，如果在 viewWillDisappear: 等方法里出现了对导航栏的样式修改的操作，如果有，请做调整。检查是否有改动 translucent 属性，包括显示修改和隐式修改，如果有，请做调整。只关心当前页面的样式永远记住每个 ViewController 只用关心自己的样式，设置的时机点在 viewWillAppear: 或者 viewDidLoad 里。透明样式导航栏的正确设置方法如果需要一个透明效果的导航栏，可以使用如下代码实现：[self.navigationController.navigationBar setBackgroundImage:[UIImage new] forBarMetrics:UIBarMetricsDefault];self.navigationController.navigationBar.shadowImage = [UIImage new]; 导航栏的颜色渐变效果如果需要导航栏实现随滚动改变整体 alpha 值的效果，可以通过改变 setBackgroundImage:forBarMetrics: 方法里 image 的 alpha 值来达到目标，这里一般是使用监听 scrollView.contentOffset 的手段来做。请避免直接修改 NavigationBar 的 alpha 值。还有一点需要注意的是，在页面转场的过程中，也会触发 contentOffset 的变化，所以请尽量在 disappear 的时候取消监听。否则会容易出现导航栏透明度的变化。导航栏背景图片的规范请避免背景图里的像素点没有 alpha 通道或者 alpha 全部等于 1，容易触发 translucent 的隐式改变。如果真的要隐藏导航栏如果我们需要隐藏导航栏，请保证所有的 ViewController 能坚持如下原则：每个 ViewController 只需要关心当前页面下的导航栏是否被隐藏。在 viewWillAppear: 中，统一设置导航栏的隐藏状态。使用 setNavigationBarHidden:animated: 方法，而不是 setNavigationBarHidden:。转场动画与导航栏隐藏动画的一致性如果在转场的过程中还会显示或者隐藏导航栏的话，请保证两个方法的动画参数一致。- (void)viewWillAppear:(BOOL)animated{ [self.navigationController setNavigationBarHidden:YES animated:animated];}viewWillAppear: 里的 animated 参数是受 push 和 pop 方法里 animated 参数影响。导航栏固有的系统问题目前已知的有两个系统问题如下：当前后两个 ViewController 的导航栏都处于隐藏状态，然后在后一个 ViewController 中使用返回手势 pop 到一半时取消，再连续 push 多个页面时会造成导航栏的 Stack 混乱或者 Crash。当页面的层级结构大体如下所示时，在红色导航栏的 Stack 中，返回手势会大概率的出现跨层级的跳转，多次后会导致整个导航栏的 Stack 错乱或者 Crash。导航栏内置组件的布局规范导航栏里的组件布局在 iOS 11 后发生了改变，原有的一些解决方案已经失效，这些内容不在本篇文章的讨论范围之内，推荐阅读UIBarButtonItem 在 iOS 11 上的改变及应对方案，这篇文章详细的解释了 iOS 11 里的变化和可行的应对方案。总结本文涉及内容较多，从 iOS 系统下的导航栏概念到大型应用里的最佳实践，这里我们总结一下整篇文章的核心内容：理解导航栏组件的结构和相关方法的生命周期。导航栏组件的结构留有 MVC 架构的影子，在解决问题时，要去相应的层级处理。转场问题的关键点是方法的调用顺序，所以了解生命周期是解决此类问题的基础。状态管理，转换时机和样式变化是导航栏里常见问题的三种表现形式，遇到实际问题时需要区分清楚。状态管理要坚持“谁修改，谁复原”的原则。转换时机的设定要做到连续可执行。样式变化的核心点是导航栏的显示与否与颜色变化。为了更好的配合大型应用里的路由系统，导航栏转场的常见解决方案有三种，各有利弊，需要根据自身的业务场景和历史包袱做取舍。解决方案1：自定义导航栏组件。解决方案2：在原有导航栏组件里添加 Fake Bar。解决方案3：在导航栏转场过程中添加 Fake Bar。美团在实际开发过程中采用了第三种方案，并给出了适合美团 App 的最佳实践。特别感谢莫洲骐在此项目里的贡献与付出。参考链接UIAppearance Tutorial: Getting StartedKMNavigationBarTransition作者简介思琦，美团点评 iOS 工程师。2016 年加入美团，负责美团平台的业务开发及 UI 组件的维护工作。招聘美团平台诚招 iOS、Android、FE 高级/资深工程师和技术专家，Base 北京、上海、成都，欢迎有兴趣的同学投递简历到zhangsiqi04@meituan.com。 ...