Colingo碎碎念

创建java8镜像

工作有时候可能需要自己创建一个镜像。过程有点小复杂，时间长容易忘记，记录一下自己创建java8与tomcat绑一起的镜像。

微信支付与授权，并不是每个项目都会使用，有一定的业务倾向性。工作好多年的工程师可能都没有接触过这个。再加上这些功能的开发，都要去微信的管理后台进行配置，一般工程师也没有这个权限，也只能网上看看再和相关的同事说怎么开通哪个服务。

最近接触支付与授权，稍微记录一下。

授权相关

公众号，提供服务，但要求用户要关注公众号，才可以进行使用相关的服务。

实施微服务架构，我们一直在遵循一个实践原则：每个微服务要有自己独立的数据库，避免数据库层面的耦合。这种理所当然感觉好像不需要多加思考，就是应该这样做。

那么到底为什么每个微服务都需要独立的数据库，数据放在一个数据库有问题吗？马丁•福勒 微服务

“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.”

大约六年前，我加入了LinkedIn。我们刚开始遇到单体集中式数据库的限制，需要开始过渡到一个专门的分布式系统组合。这是一个有趣的经历：我们建立、部署并运行至今的分布式图形数据库、分布式搜索后端、Hadoop安装，以及第一代和第二代键值存储。

在这一过程中，我学到的最有用的东西之一是我们正在构建的许多东西，其核心是一个非常简单的概念：日志。日志有时被称为写前日志或提交日志或交易日志，它的存在时间几乎与计算机一样长，是许多分布式数据系统和实时应用架构的核心。

如果不了解日志，你就无法完全理解数据库、NoSQL存储、键值存储、复制、paxos、hadoop、版本控制或几乎所有的软件系统；然而，大多数软件工程师对它们并不熟悉。我想改变这种状况。在这篇文章中，我将带领你了解关于日志的一切，包括什么是日志以及如何使用日志进行数据整合、实时处理和系统建设。

开始

对长期做业务开发的同学来说，写代码可能是件容易的事情，也可能是件很麻烦的事情。说容易，主要是因为需求基本上是CRUD(增、查、改、删)，再复杂的业务，也可以这么做(有点事务脚本的意思)来实现需求。说复杂或麻烦呢，主要是考虑如何分工，如果划分职责，把package分清楚，可能就是一件很繁琐和有挑战的事情。

摘要

Raft 是一种为了管理复制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能，但是它的算法结构和 Paxos 不同，使得 Raft 算法更加容易理解并且更容易构建实际的系统。为了提升可理解性，Raft 将一致性算法分解成了几个关键模块，例如leader选举、日志复制和安全性。同时它通过实施一个更强的一致性来减少需要考虑的状态的数量。从一个用户研究的结果可以证明，对于学生而言，Raft 算法比 Paxos 算法更加容易学习。Raft 算法还包括一个新的机制来允许集群成员的动态改变，它利用重叠的大多数来保证安全性。

在DDD实践中，聚合应该作为一个完整的单元进行读取和持久化，简言之：DDD持久化时，是保存聚合根。这样做主要是为了“以确保业务的不变性或者说业务规则不变破坏”，如果聚合根只有自己一个Entity，没什么值得讨论的。但是现实中，聚合根下可能会有多个Entity。如：订单总金额应该与订单明细金额之和一致。看了一些讲解DDD的资料，要么是将聚合保存到文件里、要么是将聚合以JSON方式存储在DB里。显然并不满足大多数的需求！
如何优雅的实现持久化？如果我们使用JPA，Hibernate，很多事情无需我们关心，ORM已经处理好了。然而，现在Hibernate这类的ORM在国内已经没有当年那么流行了。Mybatis这类半自动的ORM怎么处理这个问题，更值得思考与讨论。

业务库存，在途库存，虚拟(以销定采)

实物库存，库位库存，批次库存

本文来自己张健飞的blog。

复杂性来自哪里

可扩展性差

对于只有一个业务的简单场景，并不需要扩展，问题也不突出，这也是为什么这个点经常被忽略的原因，因为我们大部分的系统都是从单一业务开始的。但是随着支持的业务越来越多，代码里面开始出现大量的if-else逻辑，这个时候代码开始有坏味道，没闻到的同学就这么继续往上堆，闻到的同学会重构一下，但因为系统没有统一的可扩展架构，重构的技法也各不相同，这种代码的不一致性也是一种理解上的复杂度。久而久之，系统就变得复杂难维护。像我们CRM应用，有N个业务方，每个业务方又有N个租户，如果都要用if-else判断业务差异，那简直就是惨绝人寰。其实这种扩展点（Extension Point），或者叫插件（Plug-in）的设计在架构设计中是非常普遍的。比较成功的案例有eclipse的plug-in机制，集团的TMF2.0架构。还有一个扩展性需求就是字段扩展，这一点对SaaS应用尤为重要，因为有很多客户定制化需求，但是我们很多系统也没有统一的字段扩展方案。

If-else， 字段扩展
对于字段扩展，简单一点的解决方案就是预留扩展字段，复杂一点的就是使用元数据引擎。使用元数据的好处是不仅能支持字段扩展，还提供了丰富的字段描述，等于是为以后的SaaS化配置提供了可能性，所以我们选择了使用元数据引擎。