短链服务的鼻祖是 TinyURL，是最早提供短链服务的网站，目前国内也有很多短链服务：新浪（t.cn）、百度（dwz.cn）、腾讯（url.cn）等等。

不得不问一句，为什么要用短链？这个问题的另外一层意思是，短链服务有必要存在吗？

套用万金油答案：存在即合理。

用了 Git 多年，优势和挑战都是深有体会。

话不多说，直接上问题：如何在微服务团队中高效使用 Git 管理代码？

继续不多话，直接上答案：分支管理。

目前数据存储设备越来越便宜，已经不存在为了节省空间而引入复杂计算的场景，但是有时候，将 IPv4 这种长字符串数据转换为数字，更加便于比较和查询。

之前说过了单例模式，这周想说说建造者模式，它是另外一个比较常用的创建型设计模式。

每种设计模式的出现，都是为了解决一些编程不够优雅的问题，建造者模式也是这样。

维基百科解释是：建造者模式，Builder Pattern，又名生成器模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来（抽象类别），使这个抽象过程的不同实现方法可以构造出不同表现（属性）的对象。

微服务的优势众多，在现在如果有谁没有听过微服务架构，可以从这里了解一下。本文主要聊一聊是否值得花时间将单体架构重构为微服务架构？

本文是盖瑞·马库斯的《怪诞脑科学:战胜焦虑、混乱、拖延的自控术》一书读后感，借用作者给出的13条建议，结合自己的理解分享给大家。

我们的身体的精密程度远超机器可以比拟，大脑神经元复杂程度远远超过世界上任何已存在的机器，但是我们却没有最简单的机器那样精准计算和准确无误的存储。

我们的记忆会向我们所想要的那个方向发生偏差，比如很多嫌疑人都认为自己犯的错有情可原。我们会偶尔断片或者忘记刚放下的一个小东西，所以我们会忘带钥匙、找不到手机，或者忘了锁门。

机器就不会发生这些，只要是存储的资料，没有修改绝对不会改变，只要是设定好的程序，一定会按照预期产生相同且一致的结果。非理性思维，是产生这种情况的“罪魁祸首”，同时也是我们有别于机器的重要原因。

德国化学家厄恩斯特·费希尔（Ernst Fischer）曾陷入这样的沉思：“随着机器变得越来越完美高效，于是这就变得很清楚了——人类的伟大之处就在于他们身上存在不完美的地方。”一个由工程师设计出来的生物可能永远都不懂什么是爱，永远都学不会欣赏艺术或理解诗歌。以动物的理性来看，把时间花在创造和欣赏艺术上，还不如把其用来收集坚果，为过冬做好准备呢。而从人类的角度，艺术是生活乐趣的一部分。

尽管我们有着机器或者动物所没有的优势，但是我们大脑中那些非理性的部分，让我们固执、偏执，存在认知偏差等一系列不好的因素，阻碍了我们个人乃至我们整个人类种族的发展，所以无论如何，我们都应该做的更好。盖瑞·马库斯给出的13条建议，每一条都是建立在谨慎的实证研究基础之上的，同时，也是我们可以习得的一些好的习惯，有可能改变我们生活中各种的不如意。

《凤凰项目-一个IT运维的传奇故事》是一本比较神奇的书，用讲故事的方式，展现了IT团队（开发、测试、运维）在开发效能低、系统交付慢的情况下，通过实践三步工作法，在团队中实现加快系统交付、提升开发效能，使团队走上DevOps之路。而且本书有一个值得称道的地方是，通过类比制造业的工作流程，可以直观发现技术团队工作过程中隐藏的问题。

这里需要提醒一下开发人员，看书的时候一定要佛系，因为这个故事是以运维角度展开的，有一些大骂开发的情节。如果是想找具体的DevOps工具的，建议不要看了，里面没有具体的工具介绍，是以最朴素的方式，讲述DevOps的优势和实践。

先说一下概念：

• 价值流：一个组织基于客户的需求所执行的一系列有序的交付活动。或者，为了给客户设计、生产和提供产品或服务所需从事的一系列活动，它包含了信息流和物料流的双重价值。
• 技术价值流：把业务构想转化为向客户交付价值的、有技术驱动的服务所需要的流程。流程的输入是需求，由开发部门完成开发，进行整体测试，部署到生产环境正常运行，并为客户提供服务，以产生价值。
• 前置时间：从需求确认（开发接收需求）开始计时，到工作完成时结束
• 处理时间：从实际开始处理工作开始计时，到工作完成结束
• 等待时间：从需求确认（开发接收需求）开始计时，到实际开始处理工作时结束
• 在制品/半成品：价值流里没有彻底完成的工作、处于队列中的工作。部分完成的工作会逐渐过期，随着时间推移到最终失去价值。
• 约束点：价值流中的瓶颈，即整个价值流流速的上限点。

在 微服务的基建工作 中提到过，在云原生、微服务时代，如果还是手动修改服务地址，是几乎不可完成的工作，需要一种机制完成自动上报和获取服务地址的支撑组件，可以保障服务的快速上线和下线，这就是服务注册/发现组件。

个人认为单例模式是设计模式中最简单也是最常用的一种，是对有限资源合理利用的一种方式。这个模式看似简单，但是其中蕴含了关于并发、类加载、序列化等一系列深层次的知识，如果理解不够深，就有可能在高并发时遇到难以预期的异常，或者会造成资源浪费。

所以本文会从将目前Java领域最常用的几种单例模式列出来，供大家参考。

前文说了一下《六字说出微服务的本质》，在文末提到，初创团队不建议直接使用微服务，对于初创团队，最根本的是活下去，而想要使用微服务，需要有很多基础建设。本文就来说下，微服务都需要哪些基础建设。

需要说明的是，下面这些组件，都是基于服务太多这个前提。

微服务的出现是为了研发效能的提升：相同的人数可以处理更多的需求、维护更多的产品，可以更快的交付产品。基于这点，微服务的基础组件，就从解放人力，减少人为失误出发。

下面给出一张微服务基础组件的图片：