需求背景

复杂多变的需求——随着互联网应用的越来越广泛,传统行业兼容多种消息传输场景越来越复杂,多个异构系统之间信息交换时面临的各种问题及需求,如数据报文转换,通讯协议兼容,支持路由等。传统的通讯机功能单一,缺乏通用性,面对复杂的需求往往需要大量重复的功能开发。

广泛的应用场景——外联通讯前置平台是企业与外部系统安全连接并信息交换的重要基础设施,通过它可以解决多个系统(如中间业务系统与第三方外接系统,中间业务系统与终端系统)之间进行互连时所面临的各种问题及需求,可实现整个平台系统的集成化通讯接入,使中间业务平台上的不同应用真正融合在一起,客户提供更方便和优质的服务。

阅读全文 »

为什么需要全局唯一ID

传统的单体架构的时候,我们基本是单库然后业务单表的结构。每个业务表的ID一般我们都是从1增,通过AUTO_INCREMENT=1设置自增起始值,但是在分布式服务架构模式下分库分表的设计,使得多个库或多个表存储相同的业务数据。这种情况根据数据库的自增ID就会产生相同ID的情况,不能保证主键的唯一性。

分布式系统中生成全局id方法由很多,我们选择的时候也比较纠结。每种方式都有各自的使用场景,如果我们熟悉各种方式及优缺点,结合自身的业务,使用的时候才能更好的选择。下面先看一下几种常见的:UUID、数据库预取、雪花算法、Redis自增等等

PS:后续补充下,目前业界已经有比较多成熟的解决方案,比如:百度UidGenerato美团Leaf等,功能都非常强大,可以直接拿来适用或者借鉴!!

阅读全文 »

将 Hexo 部署到 GitHub Pages 上之后,发现访问速度较慢,并且有时侯GitHub 会被墙,访问不了,又折腾了一下将hexo部署到了vps,资料都是从网上查到的,这里做一下整理记录

准备工作

环境准备:

  • vps服务器一台,我这里使用的是Racknerd 最便宜的1c1g,14刀每年, 系统随便,我用的是CentOs7
  • 域名,我用的是 namesilo 也是因为便宜,并且不需要备案

网上部署方案有两种:

  • 将 Hexo 项目上传到 VPS 上面后执行 hexo server,之后配置 Nginx 反向代理,让域名指向 http://localhost:4000
  • 将 Hexo 在本地通过 hexo g 生成静态文件,在通过 hexo d 部署到 VPS 上面,使用 Nginx 直接做 Web 服务器。

相比第二种方式,第一种每次写博客与更新博客时候的操作会很繁琐。这里就只使用第二种方式进行部署,这样既可以将静态文件 deploy 到 VPS 上,也可以上传到 Github 上用作备份,操作性和安全性上都比第一种要高。

而对于第二种方式而言,常用的又有 git hookrsync 两种自动部署解决方案。

本文主要介绍 git hook 部署过程。

阅读全文 »
0%