yarn

.NET Core前后端分离快速开发框架(Core.3.1+AntdVue)

て烟熏妆下的殇ゞ 提交于 2020-08-12 02:51:15
.NET Core前后端分离快速开发框架(Core.3.1+AntdVue) 引言 简介 环境搭建 开发环境要求: 基础数据库构建: 数据库设计规范 运行 使用教程 系统配置 快速开发 管理员登录 系统用户管理 系统角色管理 权限管理 接口秘钥管理 系统日志 操作日志 事务使用 读写分离分库分表 常见疑问 如何进行联表查询 如何切换数据库类型 如何使用多个数据库 结语 引言 时间真快,转眼今年又要过去了。回想今年,依次开源发布了 Colder.Fx.Net.AdminLTE(254Star) 、 Colder.Fx.Core.AdminLTE(335Star) 、 DotNettySocket(82Star) 、 IdHelper(47Star) ,这些框架及组件都是本着以实际出发,实事求是的态度,力求提高开发效率(我自己都是第一个使用者),目前来看反响不错。但是随着前端和后端技术的不断变革,尤其是前端,目前大环境已经是前后端完全分离为主的开发模式,在这样的大环境和必然趋势之下,传统的MVC就显得有些落伍了。在这样的背景下,一款前后端分离的.NET开发框架就显得尤为必要,由此便定了框架的升级目标: 前后端分离 。 首先后端技术的选择,从目前的数据来看,.NET Core的发展远远快于.NET Framework,最简单的分析就是Colder.Fx.Core

总结:ZooKeeper

元气小坏坏 提交于 2020-08-12 00:21:38
一、ZooKeeper数据模型 从图中我们可以看出ZooKeeper的数据模型,在结构上和标准文件系统的非常相似,都是采用这种树形层次结构, ZooKeeper树中的每个节点被称为—Znode 。和文件系统的目录树一样,ZooKeeper树中的每个节点可以拥有子节点。但也有不同之处: (1) 引用方式   Zonde通过 路径引用 ,如同Unix中的文件路径。 路径必须是绝对的 ,因此他们必须由斜杠字符来开头。 除此以外,他们 必须是唯一的,也就是说每一个路径只有一个表示,因此这些路径不能改变 。在ZooKeeper中,路径由Unicode字符串组成,并且有一些限制。字符串"/zookeeper"用以保存管理信息,比如关键配额信息。 (2) Znode结构   ZooKeeper命名空间中的 Znode,兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构,又像目录一样可以作为路径标识的一部分。 图中的每个节点称为一个Znode。 每个 Znode由3部分组成 :    ① stat :此为状态信息, 描述该Znode的版本, 权限等信息    ② data :与该Znode关联的数据    ③ children :该Znode下的子节点   ZooKeeper虽然可以关联一些数据,但并没有被设计为常规的数据库或者大数据存储,相反的是,它用来

Flink详细笔记(一) Flink简介

送分小仙女□ 提交于 2020-08-11 22:22:13
随着5G时代的到来,未来都将会是万物互联,各种各样的设备都会与网络连接起来。未来有无人驾驶、很多的设备都能接入到5G,会有大量的数据产生。 以后这些数据都将需要做实时分析,有人把Flink归类为第三代大数据引擎。第一代:Hadoop、第二代:Spark 。 1.什么是 Flink Flink官网:https://flink.apache.org/ Apache Flink 是一个分布式大数据处理引擎,可对1.有限数据流和2.无线数据流进行有状态计算。可部署在各种集群环境,对各种大小的数据规模进行快速计算。 名词解释: 有限数据流:即数据已经产生,数据大小已经确定。数据有限,可以做离线计算; 无限数据流:即数据流一旦产生,不知道什么时候结束。比如:数据实时写入到Kafka。数据无限,可以做实时计算。 1.1.Flink设计初衷 Flink 设计之初,就是为实时计算而设计的。但是因为其计算引擎过于强大,所以也可以做离线计算。它可以部署在各种各样的集群中,比如 Flink自己的 standalone 集群,flink on yarn部署,Flink 还可以跑在K8S上,Flink 还可以跑在各种各样的集群上。Flink为了开发测试比较方便,还可以使用单机模式。可以对各种大小规模的数据进行快速计算。特点就是:快。 1.2.Flink历史介绍 早在 2008年,Flink

以太坊 助记词提取 账户 公钥 私钥 最新实现可用。

瘦欲@ 提交于 2020-08-11 20:51:47
step 1 装依赖的包(npm/yarn 自己选一个): yarn add bip39 ethereumjs-wallet ethereumjs- util npm install bip39 ethereumjs-wallet ethereumjs-util step 2 演示代码: const bip39 = require('bip39' ) const {hdkey} = require('ethereumjs-wallet' ) const util = require('ethereumjs-util' ) // 1 生成助记词 ;1.1 和 1.2 自己按需。 // 1.1 生成助记词 ;这里用生成的. // let mnemonic = bip39.generateMnemonic() // 1.2 生成助记词 ;这里用写死的. let mnemonic = "hold scale hybrid tank dilemma bullet ship language attitude rug tennis host" console.log(mnemonic) // 2.将助记词转成seed getSeed = async ()=> { let seed = await bip39.mnemonicToSeed(mnemonic) console.log( "seed

Flink 中的应用部署:当前状态与新应用模式

a 夏天 提交于 2020-08-11 19:19:59
云栖号资讯:【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来! 作为现代企业的重要工具,流处理和实时分析这类工具逐渐兴起,越来越多的企业以 Apache Flink 为核心构建平台,并将其作为服务在内部提供。在最新举办的 Flink Forward 会议中, Uber 、 Netflix 和 阿里巴巴等公司的许多相关主题演讲进一步说明了这一趋势。 这些平台旨在通过减轻最终用户的所有运营负担来简化内部的 Application (应用)提交。为了提交 Flink 应用程序,这些平台通常只公开一个集中式或低并行度端点(例如 Web 前端)用于应用提交,我们将调用 Deployer(部署器)。 平台开发人员和维护人员经常提到的障碍之一是,Deployer 可能是一个很难配置的大量资源消耗者。如果按照平均负载进行配置,可能会导致 Deployer 服务被部署请求淹没(在最坏的情况下,短时间内对所有生产应用程序都是如此),而按照最高负载进行规划的话,又会带来不必要的成本。根据这一观察结果,Flink 1.11 引入了 Application 模式(应用模式)作为部署选项,它允许一个轻量级、更可伸缩性的应用提交过程,从而使应用程序部署负载更均匀地分布在集群的各个节点上。 为了理解这个问题以及了解 Application 模式如何解决该问题

nodejs 发送qq邮件 nodemailer

一世执手 提交于 2020-08-11 09:30:20
官网 https://nodemailer.com/about/ https://www.cnblogs.com/jackson-yqj/p/10154296.html 获取qq邮箱授权码, 需要使用手机发送短信 发送成功 安装, 这里使用yarn安装时出现了错误, 换成npm就ok了 cnpm i nodemailer -D 官方案例 发送qq邮件 授权码十分重要, 主要保护好隐私 发送多个邮箱时, 使用的是字符串拼接, 而不是数组 可以发送html, 但是图片的话没有测试 https://www.jianshu.com/p/04e596da7d33 const nodemailer = require("nodemailer"); const _user = '504595380@qq.com' const _pwd = 'xxx' async function main() { let transporter = nodemailer.createTransport({ host: "smtp.qq.com", port: 465, secure: true, // true for 465, false for other ports auth: { user: _user, // generated ethereal user pass: _pwd, //

Jeecg Boot 的安装部署

半城伤御伤魂 提交于 2020-08-11 08:01:28
环境 操作系统:Ubuntu Kylin 优麒麟 20.04 LTS 适用架构:AMD64、ARM64(鲲鹏、飞腾) Java/JDK sudo apt install default-jdk 查看一下版本 java --version 输出的结果 openjdk 11.0.8 2020-07-14 OpenJDK Runtime Environment (build 11.0.8+10-post-Ubuntu-0ubuntu120.04) OpenJDK 64-Bit Server VM (build 11.0.8+10-post-Ubuntu-0ubuntu120.04, mixed mode) 开发工具 IDEA https://www.jetbrains.com/zh-cn/idea/ 该工具为绿色版本,在文件夹的 bin 目录中,执行 idea.sh 就可以了。 ./idea.sh 克隆项目 Git sudo apt install git GitHub 和 GitEE 码云,都有源码。 git clone https://gitee.com/jeecg/jeecg-boot.git 前端安装 npm sudo apt install npm 查看 npm 镜像 npm get registry 配置Nodejs镜像。 永久设置淘宝镜像,否则,npm 软件包的下载速度感人

用前端姿势玩docker【四】基于docker快速构建webpack的开发与生产环境

泪湿孤枕 提交于 2020-08-11 02:58:33
目录 用前端姿势玩docker【一】Docker通俗理解常用功能汇总与操作埋坑 用前端姿势玩docker【二】dockerfile定制镜像初体验 用前端姿势玩docker【三】基于nvm的前端环境构建技巧 用前端姿势玩docker【四】基于docker快速构建webpack的开发与生产环境 用前端姿势玩docker【五】快速构建中类Unix系统与Windows系统的差量化处理【待发布,请持续关注】 前言 关于docker构建前端环境,相关的坑点与难点,基本上都在这儿了,很多都是个人尝试总结的经验,都是从小白过来的,希望能帮助大家快速解决一些问题,抛开前端环境来看,差不多点的镜像基本也够用了。反而前端对易用性的要求更高(前端开发人员可不是天天跟linux打交道),还需要考虑类unix系统与windows的差异化问题,这点会在下一篇文章中重点说明。 打赏啥的也不需要,如果可以,很感激能在github上给个小星星,github入口在 博客最顶部 回顾 之前也说过 docker对于前端而言组重要的两个优势: 工作环境的快速构建 工作环境的统一 所以利用docker的工程化工作流在想象中应该是这样的: 例如一个新人从0到1构建前端环境: 安装docker => 拉取镜像 => 根据环境(dev、build)的不同传入不同的环境变量运行相应的容器 至此ok,易用性做到位之后

vue状态管理模式之vuex

北战南征 提交于 2020-08-11 02:37:28
Vuex 是什么? Vuex 是一个专为 Vue.js 应用程序开发的状态管理模式。它采用集中式存储管理应用的所有组件的状态,并以相应的规则保证状态以一种可预测的方式发生变化。Vuex 也集成到 Vue 的官方调试工具 devtools extension ,提供了诸如零配置的 time-travel 调试、状态快照导入导出等高级调试功能。 状态管理应用包含什么? new Vue({ // state 驱动应用的数据源 data () { return { count: 0 } }, // view 以声明方式将state映射到视图 template: ` <div>{{ count }}</div> `, // actions 响应再view上的用户输入导致的状态变化 methods: { increment () { this .count++ } } }) 为什么要用vuex? 当多个组件共享状态时,单向数据流的简洁性很容易被破坏。vuex的思想就是把组件的共享状态抽离出来,以全局单例模式进行管理。 构建中大型单页面应用时,需要更多的在组件外部管理状态,vuex自然而然地就是最好的选择。 安装vuex // 直接引用 <script src="/path/to/vue.js"></script> <script src="/path/to/vuex.js"></script>

Flink双流操作

痞子三分冷 提交于 2020-08-11 01:57:58
Flink 系列博客 Flink QuickStart Flink双流操作 Flink on Yarn Kerberos的配置 Flink on Yarn部署和任务提交操作 Flink配置Prometheus监控 Flink in docker 部署 Flink HA 部署 Flink 常见调优参数总结 Flink 源码之任务提交流程分析 Flink 源码之基本算子 Flink 源码之Trigger Flink 源码之Evictor 简介 Flink 双数据流转换为单数据流操作的运算有 cogroup , join 和 coflatmap 。下面为大家对比介绍下这3个运算的功能和用法。 Join :只输出条件匹配的元素对。 CoGroup : 除了输出匹配的元素对以外,未能匹配的元素也会输出。 CoFlatMap :没有匹配条件,不进行匹配,分别处理两个流的元素。在此基础上完全可以实现join和cogroup的功能,比他们使用上更加自由。 对于join和cogroup来说,代码结构大致如下: val stream1 = ... val stream2 = ... stream1.join(stream2) .where(_._1).equalTo(_._1) //join的条件stream1中的某个字段和stream2中的字段值相等 .window(...) // 指定window