2018-01-26 曹祖鹏

起因

刚进2018年，区块链突然大热，程序员们可能莫名其妙，不就是一个分布式系统么，怎么突然就要改变互联网了？还是按照我们熟悉的分布式系统设计分析开始，我们了解一些区块链的基础知识，看看是否可以改变世界。

UTXO是什么

UTXO是Unspent Transaction Output（未消费交易输出）简写。这绝对是比特币的非常特殊的地方，理解UTXO也就理解了比特币去中心化的含义。

说起UTXO必须先要介绍交易模型。以我们平时对交易的理解，我给张三转账了一笔100块钱，那就是我的账上的钱少了100，张三账上的钱多了100。我们再把问题稍微复杂一些，我和张三合起来买一个李四的一个商品390块钱。我的账户支付100，张三账户支付300，李四的帐户获得390，支付宝账户获得了10块钱的转账手续费。那么对这比交易的记录应该是这样的：

2017-12-06 曹祖鹏

好久没更新博客了，很多人催促我更新，最近因为公司的事情一直是忙（其实是懒病发作），特别是被推广了一波后，再不更对不起读者了。

上周我参加了在南京举办的IAS的架构师峰会，和很多同行沟通，特别是和当当网的首席架构师张亮做了一个结对的分享 —《技术架构演变全景图—从单体式到云原生》，分享的形式很特殊，采用了一问一答的方式，我作为提问题的，不断“刁难”张亮，张亮一一解答问题，一番“交锋”后，听众有反馈效果不错，我自己也收获了不少。

最重要的一点体会是Java未来也许不再是一个电商首选语言了。当然在互联网其他领域，Java早就不是首选了，开发繁琐，包体积大、运行时开销大等等，都不适合互联网创业。但是对于互联网电商来说，前面有阿里、京东全线转型Java技术栈的案例，后面像饿了么这样的新兴电商也慢慢的从Python转向Java，示范作用很强。以至于我们这样的电商软件提供商，把整体是Java架构当做卖点之一。
more >>

2017-8-26 曹祖鹏

背景

我们惯常开发的概念中，一直以CRUD为主（Create、Retrieve、Update、Delete），默认我们读操作（Retrieve）的对象模型和写操作（Create、Update、Delete）是同一个对象、同一张表，这对简单的业务逻辑来说，比较合适，但是在复杂的业务逻辑下，CRUD就有点力不从心了。

在领域驱动设计的实践中，我一直有个问题没想明白 – 领域聚合对象对于某一类事物的抽象是很准确的，比如库存、商品、会员，这个和现实生活中的能一一对应上。通过充血模型将数据和行为统一起来，很容易理解。
但是类似订单、审批流程，这类逻辑一直没有很好的抽象方式。从内部状态看，他纯粹是个有限状态机，没啥特别的商业逻辑；从行为看，却发现他的所有状态变更，都是需要调用外部模块，并根据外部模块的返回结果，再确定迁越到哪个状态。这和我们以前充血模型中将行为控制在只修改本身状态的做法是相抵触的。
比如库存实体，不管是出库、入库、下单、发货、上架、下架，改变的只是库存商品的状态和数量，不涉及外部模块。
但是对比订单，它的下单、支付、发货、签收等需要支付、库存、配送模块一起配合返回结果，还要处理其他模块的各种各样的失败情况（库存不足，用户没钱支付、用户拒收等等）。
这就尴尬了，这样的实体聚合的方法必须依赖外部模块，耦合拆不开，系统不能自洽，它的开发、测试、部署上线都是麻烦的事情。
这个疑惑直到我了解Saga

原文 http://static.olivergierke.de/lectures/ddd-and-spring/

1、介绍
这篇文章是的介绍一下领域驱动设计的基础构件、概念和Java的web应用（主要是基于Spring框架）之间的关系和区别。
这篇文章的第二部分讲了怎么把实体、聚合根、仓储映射到使用Spring框架的Java应用中
2、领域驱动设计
Eric Evans的《领域驱动设计》无疑是软件设计领域最重要的几本书之一。
这本书主要集中在软件开发中如何处理领域和软件的映射关系— 开始强调领域通用语言(domain ubiquitous language)，通过语言来提取模型，最终映射到一个可工作的软件上。
我们已经对软件设计模式比较熟悉了，他是用于描述和提炼Class和Class关系的技术语言。而DDD是一种用于程序员和业务沟通的更通用的语言，使用DDD可以最终将代码映射到模型上。

2017-6-16 曹祖鹏

接上篇，我们采用了领域驱动的开发方式，使用了充血模型，享受了他的好处，但是也不得不面对他带来的弊端。这个弊端在分布式的微服务架构下面又被放大。

事务一致性

事务一致性的问题在Monolithic下面不是大问题，在微服务下面却是很致命，我们回顾一下所谓的ACID原则

• Atomicity - 原子性，改变数据状态要么是一起完成，要么一起失败
• Consistency - 一致性，数据的状态是完整一致的
• Isolation - 隔离线，即使有并发事务，互相之间也不影响
• Durability - 持久性， 一旦事务提交，不可撤销

2017-6-12 曹祖鹏
上篇我们聊了微服务的DDD之间的关系，很多人还是觉得很虚幻，DDD那么复杂的理论，聚合根、值对象、事件溯源，到底我们该怎么入手呢？
实际上DDD和面向对象设计、设计模式等等理论有千丝万缕的联系，如果不熟悉OOA、OOD，DDD也是使用不好的。不过学习这些OO理论的时候，大家往往感觉到无用武之地，因为大部分的Java程序员开发生涯是从学习J2EE经典的分层理论开始的（Action、Service、Dao），在这种分层理论中，我们基本没有啥机会使用那些所谓的“行为型”的设计模式，这里的核心原因，就是J2EE经典分层的开发方式是“贫血模型”。
Martin Fowler在他的《企业应用架构模式》这本书中提出了两种开发方式“事务脚本”和“领域模型”，这两种开发分别对应了“贫血模型”和“充血模型”。

2017-6-9 曹祖鹏

微服务架构和SOA区别

微服务现在辣么火，业界流行的对比的却都是所谓的Monolithic单体应用，而大量的系统在十几年前都是已经是分布式系统了，那么微服务作为新的理念和原来的分布式系统，或者说SOA（面向服务架构）是什么区别呢？

微服务是什么

MicroService主要是针对以前的Monolithic（单体）服务来说的，类似优步打车（Uber）这样的应用，如果使用Monolithic来架构，可能是这样的

注：
STRIPE是支付服务
SENDGRID是邮件推送服务
TWILIO是语音、消息的云服务

大部分的项目都是由Monolithic起步的。刚开始最合适不过了，开发简单直接（直接在一个IDE里面就可以调试）、部署方便（搞个war包扔到tomcat里面就能跑）。
但是随着时间的增长，单体应用的缺陷暴露出来了。

事情经过

2月1号上午10点

sales api应用在70网段的104服务器 的dubbo thread线程池 满了，主数据库maindb、商品数据库itemdb连接池都占满，紧急重启后一分钟，线程池、连接池还是占满，重启了2次还是这个情况，只得应用关闭。

下午3点

sales api在66网段所有应用的线程池、连接池全满。重启后依旧，不断重启了20分钟左右，只得放弃，随后暂时关闭前端的sales web的正式环境，只保留灰度环境，然后再启动sales api，这次终于成功启动了，但是后台应用还是不断的出现线程满的情况，直到4点15分暂时恢复正常。

下午5点50分

又出现所有应用线程池、连接池 全满，临时增加了sales api的应用负载到5个，未解决问题。增加主数据库和查询库连接池连接上限到100个, 仍然无效。同时DBA报告商品数据库的压力一直在16左右，即cpu在100%，业务一直处于瘫痪中

下午6点50分

DBA发现一个查询最频繁，同时耗cpu较高的sql，关闭了这个sql的接口，只保留灰度环境上的这个功能。这时商品库的压力下降到30％左右。此时，70网段的131号的sales api负载cpu较高，导致thread满。重启无效，遂关闭。