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

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

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

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

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

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

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

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

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

先说一下概念：

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

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

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

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

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

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

我所理解的微服务，就六个字：“高内聚，低耦合”。

没错，就是这个在软件开发过程中被反复提到的六个字，各类设计模式、架构设计、从入门到放弃等各种书中总会提到，从初级到高级到骨灰级程序员、架构师挂在嘴边的也是这六个字。只不过，在微服务概念之前，这六个字被用在类、模块、组件上，微服务则是将它放在服务上。

注：上面是精简版，下面是完整版，看官自便。

目前很多互联网公司都采用微服务架构，微服务的优点和缺点被反复说到，这里不在重复赘述，只结合工作中的一些实践，说说要用微服务要注意的点，厚颜写做编程范式，其实就是一些具体实践而已。

本文主要记录一次从源码安装Nginx过程，参考的是Nginx官网。

现在手机越来越便宜，换手机是比较常见的一件事，所以各大厂商为了降低更换手机的成本，也是各种手段费尽心思：一键换机、云账号。。。但是这些方式都建立在一个基础上，就是同品牌手机才能用。如果是跨品牌换机，那真是要经历九九八十一难，百转千回才能顺利使用新机。像我这种懒人，可能还要在很长一段时间继续使用旧手机。

随着微服务架构的普及，线上服务越来越多，随之而来的就是部署越来越频繁；随着互联网行业的兴旺，产品迭代的频率也是越来越快，服务上线速度逐步提升。有上线、有部署，就有风险。有风险，就对业务有影响，然后就有了一系列减少这种风险的部署方案：蓝绿部署、金丝雀发布（灰度发布），也有适应产品迭代频率的AB测试。

本文主要是简单解释下这几个概念，帮助自己理解，如果有错误，请大佬们斧正。