自动初始化Gitalk评论

原创

2018-10-31

最近重新将博客整理了一下，之前忙的都没有时间取打理。其中一下是用Gitalk更换原来的评论系统。
Gitalk是利用了GithubAPI，将网站的评论转写到Github上指定仓库的Issues里，相当于做了一个代理。风格做的简约漂亮，但每种不足的是每次发表了新博文后，需要自己用管理员账号登陆下评论系统，否则就会：

所以就萌生了写个nodejs代码去代替人工初始化的想法。

Gitalk安装

Akka入门系列(三)：remote Actor

原创

2018-10-30

Java框架分布式Akka

虽然Akka在单机上可以运行上百万的Actor，但出于容错、负载均衡、灰度发布、提高并行度等等原因，我们仍然需要能在多个不同的服务器上运行Actor。所以Akka提供了akka-remoting的扩展包，屏蔽底层网络传输的细节，让上层以及其简单的方式使用远程的Actor调度。
官方文档：https://doc.akka.io/docs/akka/current/remoting.html

适用场景

remoting的存在其实是为akka cluster做底层支持的，通常并不会直接去使用remoting的包。但为了了解cluster的底层原理，还是有必要看下remoting。
同时，remoting被设计为Peer-to-Peer而非Client-Server，所以不适用于基于后者的系统开发，比如我们无法在一个provider为local的Actor里去查找一个remote actor发送消息，必须两者均为remote actor，才满足对等。

Akka入门系列(二)：Actor

原创

2018-10-30

Java框架分布式Akka

Actor模型

由于AKka的核心是Actor，而Actor是按照Actor模型进行实现的，所以在使用Akka之前，有必要弄清楚什么是Actor模型。
Actor模型最早是1973年Carl Hewitt、Peter Bishop和Richard Seiger的论文中出现的，受物理学中的广义相对论(general relativity)和量子力学(quantum mechanics)所启发，为解决并发计算的一个数学模型。

Actor模型所推崇的哲学是”一切皆是Actor“，这与面向对象编程的”一切皆是对象“类似。
但不同的是，在模型中，Actor是一个运算实体，它遵循以下规则：

Akka入门系列(一)：基本介绍

原创

2018-10-30

Java框架分布式Akka

什么是Akka，它能干什么？

互联网系统的发展，大多数情况下都是业务倒逼的。发展过程不外乎以下几步：

最开始时，一个简单的MVC程序就可以，甚至是早期的J2EE也能得到很好的性能。
忽然某一天，系统压力大了，一些功能变得比较慢，这时会尝试去做代码重构优化，必要的地方开始使用进程内MQ以及线程池，开启异步及多线程。
再往后，单台也不能满足系统的吞吐了，这时就得上集群，前面一个负载均衡，后面部署多台相同的服务器，将压力均衡到若干服务器上，甚至数据库都开始做切片。
再往后，继续优化，将一些压力大的功能单独提出来，做成一个Service，对外部提供服务，可以是REST，也可以是RPC，用这种方式来提高服务器利用率，毕竟有些业务只需要IO，而有些业务需要很强的CPU，根据实现逻辑不同，需要的物理资源也不同。而这时，简单的负载均衡也无法适用了，需要功能相对复杂的网关或总线，并且各种分布式下的难点都出来了——调度、分布式容错、熔断、弹性、扩容、分布式事务、灰度发布、压力调整等等。

JHipster快速开发Web应用

原创

2018-02-01

Java脚手架

在基于Spring的Web项目开发中，通常存在两个问题：
普通CRUD的代码基本重复，完全是体力活；
Controller层和持久层之间的数据传递，存在不规范。有人喜欢直接返回JSON，有人喜欢用DTO，有人喜欢直接Entity。

那如何解决这个问题呢？自动生成呗。一群喜欢动脑筋（懒）的人，发明了JHipster。

JHipster是一个基于SpringBoot和Angular的快速Web应用和SpringCloud微服务的脚手架。本文将介绍如何利用JHipster快速开发Web应用。

Axon入门系列(八)：AxonFramework与SpringCloud的整合

原创

2017-04-24

Java框架CQRSAxon

上一篇里，我们在利用Axon3的DistributeCommand的JGroup支持，和DistributedEvent对AMQP的支持，实现了分布式环境下的CQRS和EventSourcing。
在这一篇中，我们将把Axon3与当下比较火热的微服务框架——SpringCloud进行整合，并将其微服务化。

写在前面的话

AxonFramework对SpringCloud的支持，是从3.0.2才开始的，但是在3.0.2和3.0.3两个版本，均存在blocking bug，所以要想与SpringCloud完成整合，版本必须大于等于3.0.4。
PS：连续跳坑，debug读代码，帮Axon找BUG，血泪换来的结论……好在社区足够活跃，作者也比较给力，连续更新。

Axon入门系列(七)：DistributeCommand和DistributeEvent

原创

2017-04-01

Java框架CQRSAxon

上一篇我们才算真正实现了一个基于Axon3的例子，本篇我们来尝试实现在分布式环境下利用Axon3做CQRS，即把CommandSide和QuerySide变成两个独立应用，分别可以启多份实例。

首先，我们回顾一下CQRS&EventSourcing模式下，整个架构的关键点，或者说最大的特点：

CommandSide和QuerySide的持久层分离；
保存对Aggregate状态造成变化的Event，而不是状态本身；
Aggregate的状态全局原子化操作；
适用于读大于写的场景；
我们前面的例子，是在一个应用里面实现了CQRS模式，而在分布式场景下，有如下要求：
CommandSide和QuerySide可以不在同一个节点(甚至不在同一个应用)下；
CommandSide不同的CommandHandler、EventHandler可以不在同一个节点；
不同CommandSide对同一个Aggregate的操作应具有原子性；
我们来一步步满足这三个要求。

Axon入门系列(六)：Saga的使用

原创

2017-03-31

Java框架CQRSAxon

在上一篇里面，我们正式的使用了CQRS模式完成了AXON的第一个真正的例子，但是细心的朋友会发现一个问题，创建订单时并没有检查商品库存。
库存是否足够直接回导致订单状态的成功与否，在并发时可能还会出现超卖。当库存不足时还需要回滚订单，所以这里出现了复杂的跨Aggregate事务问题。
Saga就是为解决这里复杂流程而生的。

Saga

Saga 这个名词最早是由Hector Garcia-Molina和Kenneth Salem写的Sagas这篇论文里提出来的，但其实Saga并不是什么新事物，在我们传统的系统设计中，它有个更熟悉的名字——“ProcessManager”，只是换了个马甲，还是干同样的事——组合一组逻辑处理复杂流程。
但它与我们平常理解的“ProgressManager”又有不同，它的提出，最早是是为了解决分布式系统中长时间运行事务(long-running business process)的问题，把单一的transaction按照步骤分成一组若干子transaction，通过补偿机制实现最终一致性。
举个例子，在一个交易环节中有下单支付两个步骤，如果是传统方式，两个步骤在一个事务里，统一成功或回滚，然而如果支付时间很长，那么就会导致第一步，即下单这里所占用的资源被长时间锁定，可能会对系统可用性造成影响。如果用Saga来实现，那么下单是一个独立事务，下单的事务先提交，提交成功后开始支付的事务，如果支付成功，则支付的事务也提交，整个流程就算完成，但是如果支付事务执行失败，那么支付需要回滚，因为这时下单事务已经提交，则需要对下单操作进行补偿操作（可能是回滚，也可能是变成新状态）。
可以看到Saga是牺牲了数据的强一致性，实现最终一致性。