主页

微服务入门,看这一篇就够了 | 分享会演讲稿

微服务,这其实是一个比较大的概念,就像问什么是「人工智能」,什么是「大数据」,什么是「区块链」一样,似乎很熟悉,但是,好像又说不出什么来。

上次在讨论产品架构的时候,我们谈到了微服务的这个方向,而我在之前公司也接触过一些这方面的工作,一直想要整理一下,所以,借着这个机会,整理出来,分享给大家,耽误大家大概半个多小时的时间,相信一定能有一些收获。

我在整理的过程中,就发现,原来之前我接触的那些工作,实在是冰山一角,微服务涉及到的内容,实在太多了,就像之前同事分享过的「数据挖掘和人工智能」课题一样,听上去很熟悉的一个话题,其实里面的内容很深且广。

目录

下面我就从这三个方面来讲一下:

  • 第一点,什么是微服务?这里会讲到微服务的发展过程;
  • 第二点,讲一下微服务架构到底包含哪些内容,这块是微服务的核心内容;
  • 第三点,简单谈一下,咱们的产品接下来可以尝试从哪个方向去做,当然这里只是给个建议,具体技术实现,可能还需要技术团队去研究。

什么是微服务

首先来看下,什么是微服务。每一个技术的发展都是由业务驱动的,这个大家没有什么异议吧。

正是由于当前技术方案已经不能满足业务需求,我们才会去研究新的技术方案,于是,就会出现一堆新的技术名词。什么负载均衡,什么 Redis,什么 MemCache 等等。

微服务也就是近几年才诞生的一个新概念,诞生的过程,我希望通过一个简单的故事介绍一下。

故事来源:https://www.zhihu.com/question/65502802 我会做一些精简,详细故事可去原文查看。

小明和小皮一起创业做网上超市,小明负责程序开发,小皮负责其他,这个「其他」一般是指产品经理。很多时候,一个程序员,一个产品经理就组成了一个创业团队。

最开始的时候,网站的功能很简单,实现业务核心功能,满足用户基本需求,就可以了,所以,第一版产品很快就上线了,它的架构大概如下图所示:

image-20200302114756010

这大概是很多初创团队产品最初的样子,分为前台,后台,数据库。

然而随着业务的发展,出现了各种竞争对手,在竞争的压力下,小皮认为,需要开展一些营销手段了(新的需求产生新的功能)。

除了新增营销的相关功能,还为了精准营销,开发了数据分析模块,同时,也支持了移动端设备,开发了微信小程序以及 APP。

开发任务多了起来,开发人员不够了,于是团队又加了一个人,负责移动端的开发。在这个阶段,产品的架构图大致如下图所示:

image-20200302120441638

可以看出,功能更加的复杂了,而整体架构没有发生太大的变化,依然是分为前台,后台以及数据库。

但是,这种架构会出现很多的问题,例如:

  • 代码重复。有很多相同业务逻辑的代码在不同的模块中;
  • 应用边界模糊,功能归属混乱。单个应用为了给其他应用提供接口,渐渐地越改越大,包含了很多本来就不属于它的逻辑。
  • 功能堆积,出现性能瓶颈。管理后台在加入数据分析和促销管理相关功能后出现性能瓶颈,影响了其他应用;
  • 开发、测试、部署、维护愈发困难。即使只改动一个小功能,也需要整个应用一起发布;
  • 团队出现推诿扯皮现象。关于一些公用的功能应该建设在哪个应用上的问题常常要争论很久;

团队很快发现,这不是长久之计,需要对产品架构进行改造,开发团队在完成正常业务的开发外,牺牲了大部分的业余时间,对一些通用的功能模块进行抽象封装,最后产品架构图如下:

image-20200302120540085

在这个阶段,引入了服务化的概念,抽象一些通用的功能模块,封装后形成公用服务,供前台调用。

虽然业务服务分开了,但是依然有一些问题,例如:数据库依然公用,对数据库的调用接口依然混乱。

因此,团队一鼓作气,将数据库也拆开了,各个业务模块形成完全独立的服务,并独立部署在独立的容器里。这时的产品架构图如下:

image-20200302120627092

到这里就有了微服务的雏形,现在简单回顾一下,微服务产生的几个发展阶段:

第一阶段:单体应用阶段,最常见的就是 LAMP 架构,对应上面得的故事,就是前两个发展阶段。这一阶段的优点是学习成本低,开发快,可以快速对产品进行试错,但是缺点也很明显。

第二阶段:服务化,抽象出公用的业务逻辑,形成公共服务。从本地方法调用的方式,变成通过接口远程调用。这个阶段,虽然采用了服务化的思路,但是,某种程度来讲,并不彻底。

第三阶段,微服务,随着 Docker 为代表的容器化技术以及敏捷开发测试的文化驱动下,使得服务化思想进一步发展,形成微服务。它与服务化的差别就是:拆分粒度更细,服务独立部署,独立维护,但对服务治理能力要求高。

微服务架构

一种技术在解决一个问题的同时,势必会带来另外一些问题。我们是否要采取某个技术方案,通常要看,它所带来的利,是否大于弊。

上面我们已经介绍了微服务的发展,从那个例子中可以看出,最后一个阶段的产品架构似乎很完善,但是,随着微服务数量越来越多,它暴露出来的问题也越来越多。

例如,怎么定义服务?如何解决服务之间调用的问题?出现故障了,如何定位哪个服务出现了问题?又怎么来解决?

好多问题,在单体应用阶段可能不值一谈,而一旦微服务数量达到几十个上百个的时候,很多问题就会被成倍放大,而微服务架构就是要去解决这些问题。

微服务架构提出了 6 大组件,分别为:服务描述、注册中心、服务框架、服务监控、服务追踪以及服务治理。

它们就是解决微服务发展过程中的那些问题而诞生。

所以,当我们在谈到微服务架构的时候,就要想到这 6 个组件都描述了哪些内容。

下面将分别来介绍这 6 个组件的基础内容。

服务描述

服务描述要解决的问题有:

  • 服务名叫什么?
  • 调用这个服务需要提供哪些信息?
  • 服务返回的结果是什么格式?
  • 如何解析结果?

我们如何定义服务,以及服务之间如何沟通,这是服务描述要解决的问题,常用的方案有三类:

RESTful API

它主要应用在 HTTP 或 HTTPS 协议的接口下,在非微服务的架构体系下,也广泛被采用。

这种方案的优点是,服务调用方几乎没有学习成本,适用于跨业务平台之间的调用。例如我们常看到平台提供 URL 供开发者调用,采用的就是这种方式。

XML 配置

它主要应用于 RPC 协议的服务。它相对于 RESTful API 会更加的高效,性能比 HTTP 协议要好。

但是,这种方式对业务代码的侵入性比较高,当配置有更新的时候,服务提供方以及服务调用方都要做相应的更新,它更适用内部系统之间的调用。

IDL(Interface description language)

这是一种通用方式,常用于 Thrift 和 gRPC 这类跨语言服务调用框架。它通过一种中立的方式来描述接口,实现跨语言平台之间的调用。

这是目前比较热门的一种技术实现方案。

注册中心

这是微服务架构里最核心的组件,它要解决的问题是:

  • 如何让外部知道你提供的服务?
  • 如何查询所需要调用的服务?

当服务数量达到几十个,甚至上百多个的时候,找服务将是一个比较棘手的问题。

注册中心就是在服务提供方与服务调用方之间,搭起一个桥梁。

打个不恰当的比方,服务描述就是规范了两个人要以哪种语言沟通,那么,注册中心,就是尽快让两人认识。

服务框架

服务框架就涉及到服务之间如何调用的问题了,它要解决的问题是:

  • 网络通信采用什么协议?
  • 数据传输采用什么方式?
  • 数据压缩采用什么格式?

网络通信分为网络连接以及请求方式。网络连接可以是基于 HTTP 协议的,也可以基于 TCP 协议;请求方式有同步,也有异步。

数据传输的协议,有基于标准的 HTTP 协议,也有自定义的一些协议,例如阿里巴巴的 Dubbo 框架就有自己的 Dubbo 协议。

数据压缩主要是为了处理特殊编码以及减少数据传输量,常用方法就是数据序列化。

还拿上面的比喻讲的话,服务框架就是两个人如何相识,是面谈还是网聊?面谈的话,是走地铁还是公交?网聊的话,是语音还是视频?

到这里服务之间就算是对接上了,接下来就是微服务的管理成本了。

服务监控

首先是如何知道服务调用是否正常,什么算是正常,什么算是不正常,这个问题相对单体应用,要复杂得多,因为服务数量多,需要监控的连接数自然也多。

它的工作流程分为 3 步:指标收集、数据处理以及数据展示。

  • 指标收集指的是要监控哪些指标,例如:响应时间,错误率等;
  • 数据处理指的是如何处理收集的指标数据,是通过接口聚合,还是需要采用数据挖掘,另外,还包括如何存储数据的问题;
  • 数据展示通常就是以看板的形式显示,能够一目了然看到所有服务的状态。

服务追踪

监控中发现的问题,是如何快速定位的?采用了什么样的技术实现?这是服务追踪组件要解决的问题。

它的原理其实很简单,就是使用「调用链」的方式。服务调用者发起请求的时候,会带用唯一标识,服务提供者会记录这次请求的唯一标识,并再生成自己的唯一标识,当还需要往下调用的时候,每一次的标识都会一层一层往下传递下去。

当某一个节点出现问题的时候,通过标识符就可以快速定位到问题所在。

服务治理

监控和追踪都是为了找到问题,而如何解决问题,还要看服务治理。

准确的说,这里不单单是指事后解决问题,而更重要的是,通过一系列的手段来保证在各种意外情况下,服务调用仍然能够正常进行。

服务治理针对不用的故障类型,会有一些对应的治理手段。

针对单机故障,也就是某一个服务节点 down 了,采用的治理手段通常是节点摘出,注册中心检测出问题后主动摘出。

另外,针对依赖的服务不可用的情况,会采用熔断(一段时间内停止发起调用,直接返回结果,缓解服务压力)的解决方案。

还有诸如负载均衡以及服务路由的治理手段,这里就不展开说了。

产品规划

介绍完了整个微服务架构的内容,看上去这似乎是一个很完善的服务化解决方案,架构里各种组件的功能也很完备,那么,是不是我们都应该要上微服务架构呀?

答案是否定的。前面说过,每一种技术的发展都是由业务驱动的,我们一定要认识到一点,技术是中立的,适合自己业务才最重要

例如,在产品验证阶段,我们一个单体应用就能解决用户痛点,满足用户需求,那么单体应用架构就是最佳的技术方案,随着业务的发展,单体应用带来的弊渐渐大于利,我们就需要考虑其他的技术方案,就像开头故事里讲的那样。

接下来,我们就要去想,我们的业务处在什么阶段,要采用什么样的技术方案?

产品是否要服务化,采用微服务架构,倒是有一些可参考的指标。例如开发人数,当数量超过 10 人,开发之间的协作就变得越来越困难,可以考虑业务拆分。

另外,产品内如果采用了不同的语言开发,例如某一个 C# 开发的数据分析软件,中间的数据处理以及分析功能,使用了机器学习的算法,而算法模块是使用 Python 开发的。

这些都是好的契机,根据业务发展,可以逐步引入服务化的概念。

最后,一定要记住,采用什么样的技术架构,一定是随着当前业务的发展,一步一步演化而来的。

附:一些名词解释

入门阶段很容易被一些概念所困惑,这块我也查了一些资料,对一些名词做简单的解释。

  • SOA(Service Oriented Architecture):面向服务体系架构,它是服务化的方法论,具有指导意义的。
  • ESB(Enterprise Service Bus):企业服务总线,它是一种模式,通过该模式,集中式软件组件可以执行与后端系统的集成(以及数据模型的转换,深度连接,路由和请求),并将这些集成和转换用作服务接口,以供新的人员重用。
  • Web Service:SOA 的一种实现技术。Web Service 基于两种协议:SOAP 和 REST协议。现在常用的是 REST 协议。

有个比喻感觉挺好,贴过来:

SOA 是方法论,就像建筑学一样,指导性质的; ESB 是建筑图纸,理顺整个建筑的架构; Web Service 是具体的建筑材料,就好像预制板;

微服务可以说是 ESB 的进一步细化,是它的升级版,ESB 更多是解决不同平台之间的数据通信问题。

而微服务进一步细化,将单个应用程序的内部再分解为小块,这些小块可独立更改,扩展和管理,随着虚拟化,云计算,敏捷开发实践和 DevOps 的兴起,微服务应运而生。

参考文档:


关于微服务架构的内容,我整理了一个超级脑图,在公众号上回复「微服务架构」,你将获得我整理后的完整资料。

阅读更多

一次关于微服务入门的分享会

自上周分享完产品架构,不到一个星期的时间,就要分享微服务的相关内容了。

刚接到这个任务的时候,我觉得没什么,找找资料,然后做一个优美的 PPT,基本上这个任务就算完成了。

原本是这么想的,可是到实际去做的时候,才发现,这块的资料也太乱了吧,越查心越慌,越深入越没底,这玩意根本不是现在的我能讲明白的。

也不知道自己哪来的勇气,去分享一个自己还没有入门的技术话题,最关键的还是给一堆技术开发人员去讲,这不是找虐嘛。

不过,再难也要硬着头皮上,即便是有了上一次做分享会的经验,这次的分享也是让我熬了两个晚上。

光自己入门就花了两天的时间,然后是整理内容以及消化,又花了一天的时间。

临分享前半个小时,我还在写演讲稿,做 PPT,那时感觉自己非常的充实,效率高得更是前所未有(苦笑)。

最后的结果,倒是有点意思。自我感觉讲得很垃圾,但是分享会的整体效果还不错。

讲得不好,也是意料之中的事,毕竟准备不充分,好多内容都没有讲出来,脑子里想到的,跟能够表达出来,完全不是一回事。

但是,在讨论的时候,效果却挺好的。

一方面,答疑的状态挺好,俨然一副老手的样子,丝毫看不出我也是刚入门。毕竟还是经过了高强度的突击学习,很多内容还犹记于心。

另一方面,大家对这个话题很感兴趣,讨论得也很激烈,能带动大家一起思考,也算是一个不错的分享会了。

你要知道,在信息泛滥的今天,我们不再为找不到信息而烦恼,而是如何找到有效的信息。例如,你想要学习 iOS 开发,随便一搜,到处都是现成的教程,但是,仔细一看,教程内容的质量却让人堪忧。

如果不能快速筛选出有效的信息,不仅浪费了时间,而且磨灭了激情。

而如何快速筛选出有效信息呢?知识付费是一条捷径

我在进行微服务入门学习的时候,查了很多相关的资料,不停的变换关键词搜索查询,筛选出了一些不错的免费资料,当然,也付费买了几个专栏,感觉效果还是很明显的。

免费学习资料:

如果对微服务感兴趣的话,上面这些资料倒是不错的入门信息,不妨先看看。

付费的这里就不贴出来了,免得有推销嫌疑。

等等,全篇文章到这里,似乎跟微服务入门没半毛钱关系啊。

别着急,我整理了一个超级脑图,在公众号「自由产品之路」上回复「微服务架构」,你将获得我整理后的资料。

这是我整理的关于微服务架构入门的一些资料,我认为还是有一些价值的,毕竟对海量信息进行过滤,本身就不是一件容易的事。

另外,还有我这次分享会的演讲稿,虽然讲得不怎么样,但是,经过我后期的文字整理,也是难得的一手材料。

整个稿子将会放在我的小专栏上了,有兴趣的,可以订阅我的小专栏

谢谢。

阅读更多

关注社会,关心疫情,关爱老婆,一个社区工作者家属的随笔

2020 年,对每一个中国人来说,都是心情沉重的,尤其是湖北武汉人。

我是武汉市江夏区湖泗镇的一名普通老百姓,这次疫情对我们家的影响,原本应该和大多数家庭一样,隔离在家做好防护。可是,由于我爱人是湖泗镇的社区工作者,让原本有些沉重的心情,又多了许多烦恼和担心。

1 月 22 日晚,也就是腊月二十八,我爱人心思沉闷的回到家里,让我不得其解,我心想,这是怎么了?再过两天,就要放假过年了,应该高兴才对。还没等我问她,她就简单地跟我说了当前疫情的情况,应上级要求,为了抗击疫情,保一方平安,社区工作人员取消所有假期,时刻准备着。

1 月 23 日早上,平时都是 7:30 起床的她,6 点就起来了。我知道她的工作习惯,从 2003 年在社区工作之后,只要有点啥事,总是会早早的出门。2018 年当选社区书记之后,更是如此。

就在那天,武汉封城,接下来的几天,疫情的相关报道越来越多,疫情似乎也越来越严重,越来越紧张,我虽然住在武汉,但由于所在乡镇比较偏远,倒还没有那么担心,但也隐隐觉得,落在我爱人肩上的工作,将会越来越重。

湖泗镇位于武汉市、黄石市和咸宁市的交汇处,地处偏远,但人口比较密集复杂,有 800 多栋房子,2000 多户,6000 多个居民,而社区却只有 4 个网格。

1 月 24 日,除夕那天起,她每天都是早出晚归,带领着社区工作人员及志愿者,挨家挨户给居民做防护宣传,测体温,发口罩,一户不落、一人不漏,凭借一只口罩,反反复复的在大街小巷中巡查。

这个春节我几乎是一个人在家里度过的,儿子在外地没有回来,而她为了工作,几乎没有在家,就算是回来,她的电话也总是响个不停,我有过抱怨,但,更多的是担心。

说实话,每月不高的工资,七零八碎的事务性工作,在这次疫情之前,我跟儿子早就劝过她,要不别干了,刚刚一岁的孙女也正是需要人的时候,可是她觉得领导委以重任,人民群众相信自己,总要做好了,不辜负党的培养和人民的信任。

平时正常工作倒还好,最起码早晚还能够相见,而这个春节,我几乎就没怎么见过她,几乎为零的沟通,让我们之间觉得有一种莫名的陌生感。

2 月 11 日那天,早早出门的她,到了晚上 10 点多还没有回家,打电话不接,发微信不回,让我心急如焚。后来才知道,情况紧急,她护送一个发热病人到区里医院。

从那天起至今,我的爱人再也没有回过家,直接在办公室住下了。也许是烦我唠叨,也许是为了更加方便工作,又或许是担心自己感染了,把病毒带回家里。

我每天在家里总是坐立不安,由于物质紧张,至今为止,社区工作人员都没有防护服,只有一副口罩,却要挨家挨户的排查,还要负责送发热病人到区里医院救治。

这些都不得不让我担心,这是武汉市一个偏远乡镇社区工作人员的真实情况,也是作为工作在一线社区工作人员家属的担心。

2 月 16 日,疫情防控再一次升级,全市居民严禁出门,所需生活物品,柴米油盐都直接与社区联系。现在,我想与她通个电话都非常困难,因为总是占线。

2 月 22 日,家里也没有菜了,让她给家里带点回来,送菜回来的时候,在门口远远看到她,穿着做饭用的那种罩衣,头发蓬乱,精神憔悴,明显感觉瘦了一圈,让我心疼万分,这哪还是我那熟悉的老婆呀。

心里不免有些抱怨,这叫什么事,怎么就摊在我家里了,我也不知道我能够做点什么,那天看到她发的朋友圈,说道「好想也被隔离在家,好好休息一下」,我不禁沉思。

期间,儿子也写过一篇文章,表示对妈妈的担心,说道,多一些理解和支持,也许才是最大的帮助吧。

说实话,我还是蛮佩服她的,每天指挥几十号人参与疫情的防控工作,早上部署,晚上汇报总结,亲力亲为,能做到有条不紊,着实不易。

作为一个社区工作者的家属,怜惜之余,也感同身受,对她这种不求回报的付出,心生敬意。

此时此刻,国家有难,没有她们的付出,哪能尽快的度过难关。不仅仅是她,还有很多向她一样,抗击在一线的社区工作人员,都在无私的奉献着。

由于爱人的工作,我也格外的关注起新闻联播来,也知道了「疫情就是命令,防控就是责任」,目前疫情形势严峻复杂,仍处于防控关键时期。

作为家属,我们能做的,就是在她们践行初心使命,在防控新冠肺炎的严峻斗争中,担当作为、冲锋在前的时候,多理解他们,多配合他们,多支持他们,给她们点赞。

武汉加油,中国加油!

这是老爸写给老妈的,在信纸上手写的,拍下来,发给了我,让我敲出来,发微信上,想了想,就发到这了。

阅读更多

一次关于产品架构的分享会

这是在公司的一次内部分享会,领导给的课题,让我针对公司的一个数据分析软件,做一次产品架构的分享。

拿到这个任务的时候,其实我是比较为难的,对于产品架构,如果没有对具体业务有深入的了解,也很难做出建设性的规划。

不过领导说,介绍一些方向性的东西,可能是未来几年要做的事情,不需要特别具体。

这么说的话,我信以为真的放心了。

背景

公司是一个立足于国家研究所的第三方软件公司,前几年的业务方向,基本上是外包项目制的,根据客户的需求,驻厂做定制化开发。

从今年开始,公司创始人觉得这不是长久之计,于是,想要把这些零散的项目,凝聚成一些产品,向客户提供服务。

但是,做产品的效果似乎不是很好,因为公司大都是技术开发人员,产品相关工作一直是项目经理担着,而项目经理也是技术出身,同时身上也有对应的开发任务,他们疲于应付客户的需求,很难跳脱出来,从宏观的角度,去考虑一些规划性的东西。

于是,公司决定要招聘产品经理这个岗位,而我,机缘巧合的成为了公司招聘的第一个产品经理,目前也是唯一的一个。

我的工作目前没有特别明确的边界,也没有给我具体安排到某一个项目组里,现在除了分担一些项目经理手头上有关需求类的工作,就是做一些产品规划。

产品

接触的第一个产品,是公司的一个数据分析软件。

这是前些年给客户做定制化开发,项目团队留下来的一个软件版本,后来在此基础上,又做了一些整合开发,形成了一个初步的产品。

该产品目前比较混乱,一共有 3 家客户在使用,但是,每一个客户使用的软件版本又不一样。

而实际上,该产品解决的是同一类业务需求,只是针对不同的客户,交付了不同的软件版本,而且,不同版本之间差异性还挺大,猜测应该是 copy 了一份核心代码,针对不同的客户,再重新开发交付。

所以,开发团队需要在 3 个不同的版本上面,分别根据对应客户的需求,做版本迭代以及交付,这里的交付依旧指的是项目合同制。

这样的结果就是,开发团队苦不堪言,需要维护 3 份不同的软件版本,同时,也会导致产品越来越分裂。

出现这样的结果,主要原因是客户方比较强势,且定制化的需求很多,而公司前期基本上都是开发团队驻厂开发,中间除了 CEO 进行商务的对接,剩下就是开发人员的事了。

结果自然是,客户方说做成什么样,开发人员就做成什么样,没有人去做需求的统筹分析,没有人去做产品的规划。

产品架构

背景说完了,该干活了,产品架构这种东西,我也是第一次搞,以前写规划报告,都是特别虚的东西,动不动就未来 5 年要做成什么样。

这次面对一堆技术开发人员,这种特别虚的东西,想来也不会受人待见。

但是,谈到「架构」这个词,本来就比较虚,实际不了,只能是谈一谈,产品未来几年的发展方向。

想清楚之后,就开始做呗。

任何事情都可以按照做产品的思路来开展,就把「产品架构图」当作一个产品,把「画产品架构图」当作「做产品」。

用户就是领导以及同事,背景以及需求上面谈到了,也都清楚,接下来就是做市场调研,其实就是看看网上有没有可借鉴(抄)的,看看类似的软件平台如何画的架构图。

经过一轮调研之后,就画出了第一版,现在看来,实在不堪入目。

做产品就是一个不断迭代的过程,一定要紧密的跟用户进行沟通,于是,拿出这一版,跟用户(对应的项目经理)进行讨论,听取用户的意见反馈,然后对产品进行迭代升级。

期间沟通了 3 回,也改了 3 回,直到该项目团队的所有成员,都提不出修改意见了。接下来,我就开始整理需求,准备做产品初版发布,没错,产品架构图也是要有版本号的。

最终发布了 v0.2 的版本,如下图:

拿着这个图,在分享会上,我夸夸而谈产品未来规划,原本以为从此走上人生巅峰,受世人敬仰。

谁知道,果然被打脸了,说好的只谈方向性的东西呢?说好的规划呢?

为什么分享会上,大家都在谈论功能如何实现,技术怎么落地的话题?对我画的这个图,丝毫没有兴趣,也没提出任何的建议。

好吧,产品经理果然跟程序员不是一路人,我默默的听他们聊了好长时间。

后续

不过,这个图,领导倒是还算满意(可能跟他不做技术很久有很大的关系),也许是看我分享会的后半程比较尴尬,于是,又给我布置了一个任务。

他看到架构图中,有个「微服务」的字眼,可能对这个词比较感兴趣,于是,让我继续深入一下,研究一下微服务的相关内容。

殊不知,我对「微服务」的理解,也仅仅只是知道字面上的意思。

不过,我很喜欢这种倒逼我学习的感觉,产品架构图不也是第一次画,这不都分享完了嘛。

微服务嘛,应该也不过如此。

后面才知道,还是 too young too naive 啊,微服务这个话题有点深。


针对这次分享会,我也整理了一份演讲稿,放在我的小专栏上了,有兴趣的,可以订阅我的小专栏查看。

阅读更多

产品架构分享会演讲稿

大家好,感谢大家能够参加这次分享会。

根据领导的要求,希望我能够针对这个产品做一些方向性的规划,所以,跟咱们项目团队沟通了几次,最后产出了这张架构图。

下面我将花大概半个小时的时间,给大家分享一下这张图所表达的意思。

前言

产品架构这个词定义比较宽泛,针对信息型产品,可能等同于信息架构,针对功能型产品,可能等同于功能架构。

而产品架构更多的表示信息架构和功能架构的总称。

当然,具体叫什么并不重要,重要的是要把想要说的事情,描述清楚就行了,在这里,我希望能够把咱们产品未来的发展方向说清楚,就可以了。

画架构图,有一些固有的模型,可分为层次结构,自然结构,线性结构以及矩阵结构。

最为广泛使用的就是层次结构。

在层次结构中,不同的产品架构图,表现也不一样。有的可能分支比较多,但是层数少;有点可能分支少,但是层数多。这个要看具体是什么产品(好像说了句废话)。

例如,淘宝的产品架构表现出来,肯定是分支多,层数少,因为业务范围太大,已经不仅仅只是电商这么简单了;而同样为电商行业,唯品会的产品架构图,分支就要相对少些,层数会多,因为它属于电商里的某个垂直领域。

至于怎么画,主要还得看产品自身的定位,以及产品的侧重点在哪里。

输入层

我们从这张图的最底层开始看,最底层是输入层,这个是根据我们业务方向定的。

由于是工具软件的定位,这个产品是要建立在别人已有的数据仓库基础上,我们的输入来源是客户端数据平台或文件系统里的试验数据。

我把这个叫做输入层,对于产品来说,这里的工作相对比较被动,但是由于咱们软件所在行业的特殊性,这里的工作又非常重要的。

如果能做到反过来去规范客户方输入的数据格式,那将是非常有意义的一件事情。

从龙哥那边了解,老板那边可能想要做成像 Excel 那样的工具。 但是咱们与之不同的是,我们需要做培养用户习惯的工作,而 Office 是软件时代的开创,它是带领用户习惯的。 所以,你看,我们现在的 Windows 桌面端软件,几乎都是照着 Office 软件的界面设计的。这就是差距。 这些都是题外话了。

所以,我这里单独把管理规范列出来了,这也是我们要去做的工作,从之前几次项目组的沟通会上了解到,目前咱们开发人员的痛点,从大面上讲,其实就是两点:数据标准化问题,以及业务流程标准化问题。

回到数据的输入层,咱们客户端的试验数据分为三种类型,文本数据,原始二进制,以及数据库数据。

之前我们都是对接客户的文件系统,不过,年前已经有研究所提出直接对接数据库的需求了。 我相信这个应该是趋势,随着客户方数据管理平台的逐渐上线,慢慢应该都会向这个方向发展。

再往上,数据的产生形式有两类:实时数据,以及滞后数据。

这块也是龙哥建议要区分开的,我认为还是有必要的。 两种形式对于上层数据预处理来说,采用的是完全不同的技术,也对应了不同的业务类型,这个后面再说。

输入层这块说完了,接下来往上是数据层。

数据接入层

实际上,这一层才是咱们软件平台的最底层,对我们的产品来说,首先要解决的问题是,输入过来的数据,如何接入?

这块原本想要作为独立的接入层,由于没有考虑清楚,就没有往下细化了。 到时候讨论的时候,可以看看大家有什么建议。

说到这,涉及一个问题,那就是层与层之间到底是什么关系,什么标准划分?

这里说一下我这里的标准,那就是解耦,每一层都可以拎出来作为独立的产品,独立的软件,也许是采用完全不同的语言开发的,也没有关系,定义好接口规范就可以了。

回到这里,我认为数据接入这里,其实是可以作为独立产品的。

目前我们专注于这个特定行业,有一定的优势,假如我们把所有的研究所的判读数据接入这块做了,其实是可以形成一个平台化的产品,这个产品也许就是一个 API,但是盘子够大,价值还是很明显的。

就类似于 Windows 操作系统接管了所有电脑硬件。这个比喻有点不自量力,但大体上是这个意思。

数据预处理 & 存储

接入了数据之后,接下来就是数据预处理以及存储的过程。

这块就简单说一下,因为这块的技术比较成熟了,关键是要根据业务,定义好数据格式以及数据规范。

预处理这里,我分为了三类,前面两类是大数据这块的技术。

  • 流处理主要针对实时数据的处理,主要应用从设备传感器直接拿到数据,进行预处理,对应的业务场景后面会说到;
  • 批处理主要针对超大数据的处理,以 G 或 T 为单位的数据,传统内存的方式可能无法处理,需要借助大数据的技术;

数据存储这里,分为了数据库管理、缓存管理以及文件管理等。

这块的技术也都比较成熟了,例如,数据库的分布式方案,Redis 的缓存方案,NAS 做文件管理的方案。

这里暂且这样简单提一下,细化的工作,后面再具体研究。

分析层

数据到这一层,已经相对规范了,可以对数据进行分析,产生数据价值。

利用统计分析、数据挖掘以及机器学习等技术,对数据的价值进行深挖。

把这里单独作为一层,因为在我看来,这是整个产品的核心竞争力。

什么是核心竞争力?核心竞争力是用来提高门槛的,别人即使模仿,也很难模仿到。

例如,针对实际业务,一些自主研发的算法;再例如,根据业务数据,训练出来的人工智能模型。

这些便形成了这个产品的核心竞争力,我们的核心竞争力。

业务层

业务层这里分为了上下两层,下面的资源库、用户中心以及文档管理,都是产品的一些基础功能模块。

别看简简单单的几个框,其实要做的工作挺多的。例如,在判读函数库这里,眼前要做的工作就有整理分类,那么如何分类,分类原则是什么?分类的维度又怎么定义?怎么根据不同客户,不同用户角色进行匹配?这些都是要去细化的工作。

再一个,我个人认为非常重要的一个功能模块,就是文档,这里的工作同样非常多。抛开全文检索这块,光是在线文档的撰写,都是需要花大量时间和精力去做。

针对这些内容的细化以及分工,还有优先级怎么定,后面需要项目组一块再讨论以及制定。

说完业务,接下来就是上层的微服务了。

微服务是个比较火的概念,也许并适合目前我们的业务规模,但也是平台型产品需要走的一步,可能是未来 3-5 年要去做的一些事情。

这里的大体思路,就是把我们的整体业务,进一步解耦,将功能模块抽象成一个一个的服务,可以对外,或者内部其他产品提供服务。

负载层

微服务架构的部署,就会涉及到负载均衡以及资源调度的相关技术了。

这块内容离咱们可能还有一段距离,当需要考虑到这一块的时候,说明咱们的平台已经具备一定规模了。

这一块的实施也就是水到渠成的事了。

展示层

最后一层是展示层,主要就是三个方向:浏览器端、桌面端以及移动端。

这一层的关键是要考虑功能取舍,以及用户体验的问题。

移动端提供的功能以及服务,肯定不能全部照搬桌面端,因为其中有屏幕以及技术的相关限制。

而如何取舍,就取决于业务需求了,准则就是:最大化用户价值。

其他

好了,到这里,产品架构图的主体内容就讲完了。

还有旁边列举的一些通用模块,例如:后台监控,日志管理,运维管理等等,这些都是平台搭建的过程中,一定会涉及的一些内容。

这里再简单谈一谈最右上角的「第三方」这里。

当形成平台型产品之后,我们就可以把内部的一些服务对外开发,开放的方式有三类:

  • 软件本身形成 SDK,可以与其他的软件平台集成,例如支持 Matlab 的导入等等
  • 业务层中的一些微服务,同样可以以 API 的方式对外提供服务
  • 分析层中研究的算法模型,可以以 API 的形式对外提供服务

讲到这,整个产品架构就讲完了,看看大家有什么意见,可以提出来一同讨论一下,谢谢。

另外,产品架构一定不是一成不变的,它会随着业务的发展,技术的发展,在恰当的时候,给出最合适的发展方向,所以,这也是一个不断完善迭代的过程,期待大家的意见。

谢谢。

阅读更多

我做了一个视频,也算是给抗疫做出了一点贡献吧

今天用 AE 做了一个文字视频,这是一段老家抗疫宣传的视频,音频是我老妈的声音。

1. 视频素材

这个视频的原创,前几天在网上还挺火的,应该出自湖北省的某个乡镇,音频部分是方言录制的,至于具体是哪个乡镇,还真没听出来。

这个宣传视频主要是为了告知乡镇居民们疫情的严重性,让大家不要出门,注意防范。

因为在很多的乡镇农村,大家很不重视,意识不到疫情的严重性。

原视频的文字稿写得很好,也有其他乡镇对着稿子,也录制了自己家乡的宣传视频,这不,我妈她们社区也录制了一份。

可是她只是录了音频,音频录制相对比较简单,打开手机录音机就可以了。

但是音频的宣传效果不太好,也许她只是想着在村里的大喇叭里放放吧。

于是,我照着原视频的模式,做了一个类似的文字视频,发给老妈之后,就在老家的群里传开了,似乎效果还不错。

2. 制作工具

我也是第一次做这个文字视频,查了一下才知道,原来这种形式的视频,在抖音上非常火,很容易成爆款。

由于形式简单,并且传播效果还不错,甚至发展出「第三方产业」,我发现有一堆做类似视频的工具 App,以及制作教程。

我也几乎都下载下来试了一遍,他们的商业模式都很清晰,都是会员制,普通用户要么限制视频长度,要么限制一些功能。

我倒不是不愿意付费,只是没有一款 App 能够满足我的需求,大部分 App 即使付费,视频长度也只能限制在 120 秒。

另外,还有一个问题,就是几乎都不支持导入音频,大都是提供在线录音,在线语音识别成文字。

这我就比较尴尬了,音频是现成了,而且是方言录的,无法上传,也无法识别。

倒不是说这些 App 产品有问题,只是我并不是它们的目标用户,它们都是针对短视频(抖音,快手)的场景而设计的,用户准备好稿子,打开 App,对着稿子用标准的普通话念出来,视频就自动生成了。

3. 最佳方案

像我这种「高端用户」的「高端需求」一定得要「高端工具」才能满足。

嗯,这个时代最不缺的就是教程,搜到一个评论,说用 PPT 就能做呀,我心想,没错,不就是一些文字蹦来蹦去吗,PPT 里的字体颜色动画,就能搞定。

回头一想,这得做到什么时候啊,要是让我来,恐怕是疫情都结束了,视频还没整完呢。

最后,找到了最佳解决方案:After Effects + TypeMonkey

After EffectsAdobe 公司出品的一款视频动效制作软件,TypeMonkeyAfter Effects 上的一个插件,用来一键生成这种「文字视频」的效果。

具体怎么操作,我就不再赘述了,拿着关键词,搜索一下,遍地是教程。

4. 专业成本

有了 After Effects 的加持,生成的文字动效里,想把哪行的文字样式调整成啥样,就能调整成啥样。

这才是「高端工具」该有的专业水准,代价就是成本有点高。

  1. 专业的软件得要钱吧,还好,软件有试用期,反正也许就做这一个;
  2. 学习专业软件的使用,得花时间吧,还好,多年与各种电脑软件打交道,手法还算熟练,加之视频比较简单,也没花多少时间;
  3. 运行专业软件的电脑,配置一定要高端。在这点上,成本就有点高了,让一个不带独立显卡的电脑,跑这种专业的视频制作软件,真是太为难它了。

别看很简单的 3 分钟视频,而且还是很傻瓜式操作的那种,几乎花了我一下午的时间。

中间调整细节的时候,跑死了 3 回,所以,你会看到视频中,有些文字和音频对不上,我只能说,我尽力了,我的电脑也尽力了。

导出视频之后,摸了摸它还在发烫的「脸颊」,我心疼着想到,下次一定换了你。

完。

阅读更多

默默的奉献者,写给我的老妈

有人在微博里问到「这次疫情结束之后,你最想要干什么?」,下面评论有说想吃汉堡,喝奶茶,吃火锅的;也有说想出去跑个十公里,打一下午球的;另外,竟然还有人说想要去上班的。

应该没有人想要还在家里待着吧,大都是在家里憋疯了,可是,是什么造成了大家只能在家里待着,是因为有了新冠病毒,准确的说是 2019-nCoV,这是个比较严重的问题,有了问题,总要有人去解决这些问题,不能所有人都待家里不是。

当然,你可能第一个想到的就是那些医护工作人员,以及医疗科研团队,他们冲在了这场病毒战争的最前线,他们是白衣天使,是病毒杀手,被人们歌颂赞扬,这是理所当然的。

然而,我想说的并不是他们,而是我的老妈,一名社区基层工作者。

对于我老妈的工作,我的感情一直比较复杂,更多的是不理解,在没发生疫情之前,就有些不理解了,孩子出生,我这边需要人手帮忙,她却因为工作原因过不来。

疫情发生之后,大家都躲在屋里不出门,她却还要出去挨家挨户给人们测体温,连个标准的防护口罩都没有(老家武汉,物资很紧缺,医护人员都用不上,更没人给她们了)。

这些困难就算了,还加上居民的不理解,媒体对当地 ZF 的指责,都能想象到,所有的压力势必会直接抵达基层,上不能言,下不能怨。

当看到老妈在朋友圈里,回答「疫情结束之后,最想要干什么?」这个问题的时候,我看到她说「想要尝一尝被隔离的滋味」,我依然不理解,但更多的是担心。

家人在下面回复说「辛苦了」的时候,她却说「为了居民的安全,再苦也值得」,我心想:这脑洗得够彻底。

也许我的价值观有些不对,但是,在面对「家人」和「他人」的选择时,我一定会选择家人,没错,我就是一个俗人,「奉献」这个词,还存在新华字典里,我还没有学会。

但是,对能做出「奉献」的人,我总是心怀感激以及感恩,因为社会需要这样的人,正因为他们不求回报的付出,才有我等俗人安逸稳定的生活。

可是当这个无私奉献的人,是我家人的时候,我又有些矛盾。

在这个抵抗疫情最关键的时刻,我能做的只能是多一些理解,多一些关心,希望这次的疫情尽快结束,家人一切安好,仅此而已。

阅读更多

这个年,信息量有点大,从腊月二十九到正月十五

这应该是我农历年后,发布的第一篇文章。

这个春节,信息量有点大,原本有很多的内容可以写,只是这些热点都是不好的消息,而我又没有那么感性,写不来煽情的文章,也就此作罢,况且,带娃可不是一个轻松的活。

年前上班到了最后一天,也就是 1 月 23 号,腊月二十九,那天武汉封城了。

印象中,那时的北京,对于疫情,似乎没有特别的反应,那天我照常坐 1 个多小时的地铁去上班了,在公司待了一上午,中午的时候走的。

那天上下班,也没有感到一丝紧张的氛围,还是和每天一样,城市也没有什么不一样,也和往年一样,一到春节,显得格外的空荡,仅此而已。

第二天,也就是大年三十,我们一家按照原计划驱车前往媳妇家,今年在他们家过年,那天就开始感受到紧张的氛围了,因为媒体里充斥着关于武汉疫情不好的消息。

我们也做了一些基本的防护,即便是自驾回家,还是带上了口罩,一路上没有在服务站停过,一口气就开回了家。

回到了媳妇老家,这个县城似乎什么也没有发生似的,一路上,几乎没有见到戴口罩的,在一些角落里,还能看到一堆堆聚集在一起的人们,在那里下象棋,打扑克。

我想,也许是消息传播得还不够快,也许是疫情的严重性还没有下达到地方ZF机构,整个县城几乎就没有防范意识。

家里的老人更是没有把这个疫情放在眼里,觉得只是普通的病情而已,认为谁还不得点感冒肺炎啥的。

接下来的几天,媒体各种报道,看着每天刷新的感染数据,问题越来越严重,直到这个小县城也有了一些切实的防护动作,街上开始有了宣传车以及警车,在驱逐聚集在一起的人们。

又过了几天,这个城市有了第 1 例感染者,接下来是第 2 例,第 3 例,直到媳妇老家所在的这个县城,也有了感染者,所在的小区终于也开始重视起来了,开始进行出入管控了。

初九的时候,我们回京了,并不是因为北京的感染者比老家里的少,要安全,而是因为在北京,我们至少能够控制住不出门,而在老家,家里的老人控制不住,这种传染病毒,一旦没有了人员流动,也就没有什么可怕的了。

另一方面,我甚至考虑到,即便是不幸被感染了,北京医院的应急能力,较之小县城,肯定要让人放心得多。

在将食材塞满了后备箱之后,我们就动身回北京了,为了不用在服务区停下来上厕所,一路上一口水也没有喝,原本以为可以不用下车,直接开到家里的地库,可是在进京的检查站被拦住了。

照常刷身份证通行,刷到我身份证的时候,机器滴滴的报警了,听到旁边的检查员说,疫区过来的,于是就让我们下车进行另外的登记检查测体温,我这才意识到,是我身份证的缘故,因为我是在武汉出生的。

我解释不是从湖北过来的,但还是被要求下车去服务大厅登记检查,倒不是我不愿意下车检查,而是我担心去服务大厅登记,还有风险呢。不过没办法,登记检查完,就匆匆回车里,继续驱车回家了。

接下来一路倒是顺利,回到家之后,就再也没有出过门,这次带过来的食材足够支撑半个月的。

公司要求这周在家里远程办公,远程倒是远程了,除了开了几次会议,还真谈不上办公,倒不是因为自己的工作效率低,而是原本也没有实际繁重的工作内容,即使要求去公司办公,同样也是差不多的状态。

虽然话说如此,公司的领导却不这么想,周五的时候开了一个会,明显感到老板觉得便宜了我们似的,认为大家在家里基本等于是放假。而实际情况,也确实也如此,这周我每天在办公电脑面前的时间,都不超过 2 个小时,更别谈实际工作的时间了。

我相信很多公司的管理者,都面临着这样的烦恼,员工不在身边,或是不在公司,压根就不知道该怎么管理了。我觉得这个问题,并非都是员工的问题,更大一部分是公司或者管理者的问题。

当然,经历过这个过程,我相信很多公司的管理者,都应该能从中看出一些根本问题,或是获得一些收获。例如:有些工作岗位似乎没有那么重要了;有些岗位似乎更适合远程;有些管理方式是时候调整了。

所幸,这些都不是我要考虑的问题,我依旧只是一个普通的上班族而已,对于年底入职这件事,我倒是有一些小确幸,如果年后再找工作的话,这个代价就大了,就这点,对公司,我心怀感激。

不出意外,下周应该依旧是远程办公。

元宵节快乐。

阅读更多

一个走在「产品」道路上,稍具文艺气息的 IT 工程师

我叫鲁鹏,性别男

能编码,好写作,一个偏内向的 IT 工程师

好在,我能编码(但码得不咋地),好写作(又不经常写),注重用户体验(无法证明),具有审美的眼光(不会设计)

很尴尬的一个组合

于是,我给自己的定义是「稍具文艺气息的 IT 工程师」

上大学之前,是家里的乖乖孩,几乎不具备自主意识(可能发育比较晚)

大学期间,做出了人生最重要的两个决定:一个谈对象,另一个是考研

谈对象,不仅让我出色的完成了大学学业,还解决了「找媳妇」的问题

考研,让我从此跟 IT 挂上了钩,我考上了计算机专业的研究生

然而,我依旧平庸,学习平庸,长相平庸,能力也平庸

但是,运气似乎还可以

毕业之后,来到了一家集团企业,解决了北京户口,从此扎根北京

在这家集团企业,一待就是一个合同期(5年)

一方面,在我看来,签了 5 年,就要做满 5 年,可能跟我「内向老实」的性格有关

另一方面,一眼就能看到尽头的职业生涯,跟我「放荡不羁」的性格又有那么一些冲突

于是,我选择了离开,在合同期满的那天

之后选择了一份更加安逸的工作,并且就在家旁边

原本想着工作清闲,有时间可以琢磨琢磨自己想要干的一些事情

可是,事情往往并没有你想象的那样简单

不过,不去尝试一下,又怎么知道合适不合适呢

干了几个月之后,又离职了

没错,在这个市场经济最不济的大环境下

我裸辞了

渐渐地,我开始有了一些新的想法,我的人生目标发生了改变

但是,认知的改变,并不代表你的能力马上就能跟上

离职这段时间,几乎颗粒无收,我觉得我还需要出去历练

于是,又重新开始找工作

毕业找工作那会,没有面过的试,这次全补上了

之前欠下的债,总是要还的

但,这次不再是为了安逸养老,而是为了训练自己的能力

以达到不依靠公司,也能自由的生活

是的,我的最终目标是「不上班」

不上班,不代表不工作,而是为自己工作

不上班,很难

没有了公司的庇护,你需要具备更全面的能力

只能靠自己,为自己打拼

说得简单,谈何容易

如何靠自己?靠自己就必须要打造个人 IP

如何打造个人 IP ?首先需要一款产品

一款印着我的标签,并受市场欢迎的产品

就像微信之张小龙,头条之张一鸣(奇怪为啥都姓张)

至于产品类型,还在尝试中,toC or toB,开源 or 商业

至于诞生形式,当前并不在乎,依靠大公司也好,创办公司也行(如果需要的话)

总之,得有一款自己的产品

能为之一路前行,无顾其他

未完……

阅读更多

写在年前的一些话,2020

明天还有一天工作日,今年我又坚持到了最后,记得去年也是公司最后一个走的。

为什么不提前回家过年呢?因为不回家,所以,过年对于我来说,只是 7 天假期而已,仅此而已,也就没有请假的必要了。

也不知道什么时候开始,似乎再也没有了对过年的期待,也许是去外地上学之后,也许是毕业北漂之后,也许是结婚之后。

这些都不重要,随着年龄的增长,少了些许过年的期待,是很正常的事情。

工作之后,过年的期待从一整个月的寒假,变成了短短的 7 天;恋爱之后,过年的期待从一个人的自由,变成了还要考虑 ta 的感受;结婚之后,过年的期待从无忧无虑,变成了该回谁家的烦恼;有了孩子之后,过年的期待从二人的决定,变成了还要考虑 mini ta(拖油瓶)的感受。

过年的「期待」不再是从前孩子般的单纯,多的是成人的烦恼。

2016 年带着媳妇回老家过年,2017 年在北京过年(老爸老妈来京),2018 年在老家过年,2019 年在北京过年,2020 年将在媳妇老家过年。

成家之后,回家过年的机会少了,有了孩子之后,似乎更少。老爸老妈催着你成家,然后催着要孙子,殊不知,有了孙子,儿子却越离越远。

不过,总要经历这个过程,成人就是要去面对这些问题,「而立」一方面代表着成长,另一方面也代表着独立,代表着分离。

有了自己的小家,很多事情确实也分身乏术,谁又不想回生我养我之地过年呢,除了老家,在哪里过年,似乎都没有年味。

年味不仅仅是春节的风俗习惯,也不仅仅是一家人的团团圆圆,更多的是家乡的味道,习惯的感觉。

不管你离开家乡多长时间,依然还是习惯家乡的环境,家乡的味道,即使家里条件并不好,你总能很快的适应,这就是家乡的魅力。

2017 年过年没有回老家,那是老爸老妈第一次来北京过年,还算新鲜。2019 年过年没有回去,是因为家里新添了一口人,一家人也算是在手忙脚乱之中度过。

今年没有回去,总是有各种原因(倒不是因为疫情),这是第三年没有回老家,将是第一年没有跟爸妈在一起过年。

总归是有一些失落,也有一些遗憾,不期望每年都能回老家过年,期望明年能够在一起过年吧。

这两天,朋友圈里不是在晒回家的路上,就是在晒家乡的房屋,家乡的饭菜以及家乡的人。

即使疫情肆虐,也丝毫没有影响过年的氛围,不过,还是注意一点比较好,最后,也祝大家新年快乐,家人身体健康,阖家幸福。

完。

阅读更多