3个开源生产力应用

看完本文，你将明白为什么一个简单的消息队列，能够有那么多的知识点;能够了解到Kafka的主要功能和应用场景;能够了解到Kafka的主要技术术语。了解到什么叫本分!

作为一个分布式消息系统，Kafka要有本分思想。它要搞清楚自己的定位，明白是为谁创造什么样的价值，依赖谁活着，自己的职责又是什么。

很少有系统在这么有压迫力的连环问下保持冷静，不过Kafka顶住了，它是真的勇士。

Kafka的本分核心，就是当作消息队列用。那么消息队列是什么呢?如果这个问题没法搞懂，就证明Kafka的思想觉悟并不是很高，还需要继续去思考、去深造。

为了弄清楚这个问题，我们采访了一位送牛奶的工人。

1. 送奶工的故事

牛奶好喝而且有营养，不管是牛奶子里捏出来的新鲜牛奶还是合成的牛奶，所以小区里有很多人订。

每天清晨，送奶工人都拉着一车牛奶开始送奶。刚开始，他按照本子上的门牌号，一家家的敲门，然后把牛奶塞进客户手里。有时候，客户不在家，他只好翻出通讯录找到客户的电话号码进行沟通。但过了不久，随着业务做的越来越大，送奶工对这份工作的评价只有一句话：*费力不讨好。

有的客户睡眼朦胧的开门，投诉他打扰生活;有的女客户披着睡衣就来接奶，投诉他的眼光猥琐;有的客户上班比较早，但在送奶工的路线规划上，却是奶最后送到的，于是投诉他配送不及时。

好在送奶工以前是个程序员，稍一思考，他说服老板：给每一家客户，配备一个奶箱。他的工作，只需要定时把鲜奶放入箱子里即可。至于客户什么时候去拿，拿去洗脸了还是搓手了，他并不关心。

从此，他再也没看到睡衣下若隐若现的胴体。

我们注意到，上面的场景，有两个主要的参与方：送奶工和客户。在加入奶箱之前，他们的交互是阻塞的，信息处理是低效的，而且存在严重的耦合问题，以至于送奶工看了不该看的东西。

当然，加入奶箱之后，交互逻辑就发生了变化，这是需要适应的;而且，奶箱是有成本的，如果业务量并不是很大，加这个玩意反而会增加成本。

我们来稍微see一下下：上面的奶箱，就是消息系统。每一个奶箱，就是一条消息队列。牛奶工，就是生产者;客户，就是消费者;而牛奶，就是消息。客户一直不取走奶，就是消息积压。客户和你发消息，确认奶已经收到，就是ACK...

2. 最简单的广义消息系统

消息系统!就是提供一个中间层，生产者只需要把消息提交到特定的中间层，消费者只需要从中间层去拿信息就可以了。

所以，它最简单的表现形式，就是数据库。
 

第一个阶段：全手工交付和运维

它是我们最初始的阶段，应用架构还没有进行服务化改造，也没有使用云基础设施或仅使用IaaS，没有持续集成、测试自动化，使用手工部署发布和手工运维。相信很少还有企业停留在这个阶段了。

第二个阶段：工具化地交付和运维

首先要做的是应用架构的服务化，采用微服务架构改善服务质量;其次是引入一些研发工具，如gitlab、jenkins这类孤岛式的工具解决部分问题。同时我们开始落地单模块的持续集成，但是一般还没有实现自动化的质量卡点，发布往往有自动化工具进行辅助。

第三个阶段：有限制的持续交付和自动化运维

我们进一步提升基础能力，将基础设施进行容器化改造，基于CaaS建设。另一方面，开始引入完整的工具链，打通研发数据，例如使用云效DevOps这样的工具平台,实现所有数据的完整互通。在发布能力上能做到持续部署，但是还需要一定的人工干预。这时，自动化测试已经成为主流了，服务整体可以观测，运维能够面向服务，并且是声明式的。

第四个阶段：持续交付和人工辅助自运维

我们进一步让开发同学专注于业务开发，首先在应用架构上开始大量采用无服务架构，并做到无人值守的持续部署;发布的灰度和回滚，能够在有干预的情况下尽量的自动化。观测能力从应用级别提升到业务级别，实现业务的可观测性，并且能够在人工辅助的情况下做到部分的自运维。

第五个阶段：全链路持续交付和自运维

这是我们追寻的终极目标。这个阶段我们所有的应用和基础设施采用的都是无服务架构，并做到端到端的无人值守持续交付，包括发布的回滚和灰度也是自动化的;技术设施和服务完全实现自运维。开发者真正只需要关心业务的开发和迭代。

但是，魔鬼都在细节处，当然我们真正的落地的时候仍有很多的问题需要我们去解决，借助云效这样的工具平台和ALPD的专家咨询，可以让我们少走弯路，更快的实现目标。

（编辑：孝感站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!