微服务介绍与实践总结
近年来，微服务与DevOps等概念不断热炒。两者实际上是紧密相联，又相辅相成，Docker、Mesos、Kubernates等技术方案的快速崛起，为微服务提供了更坚实土壤，使其得以更顺利地实施落地。 类似spirng-boot等技术的发展与大为传播，更是直接促进了微服务成熟化发展。本文将从与对传统单体架构服务与微服务的比较，介绍微服务，并在最后对DevOps与微服务联系做简单介绍。
quentinxxz 发布的文章
条件随机场介绍（译）Introduction to Conditional Random Fields
译者序
该文是对CRF算法的介绍，介绍清晰、浅显，不对初学者设置过多的理解障碍。而且文章最后提到的学习资料，我看过部份，值得推荐。
原文链接：http://blog.echen.me/2012/01/03/introduction-to-conditional-random-fields/
正文序
想象一下，你有 Justin Bieber 一天生活中的一连串快照，你想在这些照片上面打上活动内容的标签（吃睡、睡觉、开车等）。你会怎么做？
一种方式是忽略这些快照的本质，建立一个图片分类器。举个例子，事先给定一个月的打标快照，你可能会了学到在早上6点拍的较暗的照片很可能是在睡觉，有很多明亮颜色的照片，很可以是关于跳舞，照片中有车那应该是在开车等等。
然而，忽略顺序关联，你会丢失很多信息。例如，如果你看到一张嘴张的特写照片，那它应该打标成吃饭还是唱歌呢？如果上一张 Justin Bieber 的照片中他在吃饭或者做菜，那当前这张照片很可能是他在吃饭；但如果上一张照片中 Justin Bieber 在唱歌或者跳舞，那这张很可能是在说他也在唱歌。
因此，为了提高我们打标的准确率，我们应该结合参考相近照片，这正是条件随机场（condition random field）所做的事情
基于lucene的内嵌式kv存储
应用背景
诸多业务场景下，都有使用kv型式存储数据供快速查询的需求。正常的做法有使用HashMap存入内存，或者存入外部的nosql KV数据库/缓存。
- 使用HashMap做KV存储，速度快，但是如果数据量达到百万及至千万级时，HashMap必将占用大量的java堆内存，给应用带来极大的内存回收压力。
- 外部kv存储，以堆外（offHeap）存储的方式让我们的应用免于内存回收之忧，但其查询性能往往低于内存map。假设采用外部db的方式作kv存储，就会引入服务之间的通信成本，以基于LR(逻辑回归)实现推荐系统的打分服务为例，每次打分，须执行近求成百上万次kv查询（lr参数的查询），如此的查询量对性能的要求是极高的，如果每一次查询都要查询外部服务，那么网络io势必占用大量的时间。
此外，在工作中会发现很多算法问题，都会被转换为一种追求效率的搜索问题，高效的内嵌式kv存储就会显得更有价值。
真实流量压测工具 tcpcopy应用浅析
极为合理的测试需求
“双一十”将近，作为一个电商应用的开发人员，也是时候操心一下自己管理服务的性能问题了。平时跑得好好的服务应用，能否承受的住双十一，尤其是午夜时刻的流量冲击？到底是要加机器还是要做服务降级？机器加多少？服务降级降多少.....为回答这一系列的问题，你首先要知道服务的极限是多少。按我们这种非专业测试人士的设想，测试方法应满足如下需求：
lucene事务（译与解）
本文分两部份，第一部份为译：是对是对于lucene事务的一篇佳作《Transactional Lucene》的翻译。第二部份为解：是本人对一文中提到一些概念在源码层次的一些理解分析，参考lucene源码版本为4.10.4。《Transactional Lucene》中还提到了多commit在实际生产中的一些妙用，值得参考。