主页

工作岗位 —— 技术不行,产品来凑

这是《我的产品技术之旅》的系列文章,每篇文章,我都尽量保证是一个完整的故事,但不可避免会有些前后关联,毕竟这是一个成长的过程。

毕业季找工作那会,由于开发技能实在一般,几乎就没往程序员的方向去找,由于对系统运维这块非常感兴趣,所以,歪打正着进了一家大集团公司,做产品的工作。

当时招聘的岗位名称叫做「信息管理工程师」,很宽泛的一次词,那会也不太懂,现在看来,其实这个岗位有个更通用的名称,那就是「产品经理」。

产品经理这个岗位依然很宽泛,单单从面向用户的角度来说,就可分为 C 端产品经理和 B 端产品经理,C 端是指面向的用户是个人,B 端面向的用户是组织或企业。还有一种叫面向 G 端,特指政府或事业单位。

而我这个岗位和上面那些又有些不一样,因为不管你面向的是 C,还是 B,还是 G,都应该属于面向第三方做产品,产品是否成功,是需要接受商业市场的检验的。

而我这个岗位不需要什么检验,完成任务就行了。没错,说的就是「内部产品经理」,因为面向的用户是企业内部的部门。

我负责的产品是企业内部的信息系统,最核心的就是 ERP 系统了,业务是制造相关。

工作中所需要的技能,并非是在学校里学到的,在这个岗位上,大多数应届生几乎就是白纸一张,后面如何发展,全凭个人的学习能力了。

我在这个岗位上,并不是有天赋的那一类,但也还算不错,循规蹈矩,踏踏实实是我的优点,所以,岗位职责之内的事情,基本上都能轻松应对。

但是,不够专注是我的缺点之一,一旦我了解了基本的业务流程,能够处理绝大多数业务,我就没有动力继续深入研究下去了。当然,也有可能我的兴趣并不在此。

所以,对 ERP 系统的了解程度,大多停留在整体概览上,而无法深入。其实,ERP 系统有很多的内容可以深入,如果找一个业务点扎进去的话,可能就是另外一条职业发展路径了。

貌似 ERP 这个方向,并不是我想要走的,所以,在能够轻松应付岗位职责之后,我总是会尝试去做一些职责之外的项目,知识库的站点,就是其中的一个尝试。

同时还做了一些信息化的小项目,是在 Web 开发方向的尝试,跟在学校里盲目的学习开发技术不同的是,在这里,有很明确的用户需求以及目标,这一点是非常重要的,有需求,才有做产品的动力。

内部产品经理这个岗位,给我最大的收获是,锻炼了做产品的基本功(沟通,写作,画图等等),这些基本功,不管在什么行业的岗位上,都是软实力的体现。

我很庆幸,我做了一名「产品经理」,它带给了我更全面的思考。

阅读更多

硬广一下我的产品技术专栏

有一段时间没有写这个主题的内容了,是不是放弃做产品技术相关的事情了?

并没有,相反,想要自己在这个主题上,有更多的内容可以分享,我正在从零开始做一个「全流程」的产品。

具体要做的事情,可以看下这篇文章:2020 接下来要做的一些事情

小专栏是我在知识付费领域的一个小尝试,在这里,我想要去记录关于产品技术的一些思考,当然这些思考是基于我现有的认知而成的。

如果我的认知一直停留在原地,我想它的价值只会越来越低,所以,我需要去做一些新的尝试,来丰富自己的阅历,提升自己的认知。

这样,分享出来的思考,才会有它的价值。

也许我走的路,正好是你也想走的,而我在前面帮你躺平了一些坑,你走的时候,哪怕稍微节省了点时间,它的价值就产生了。

我很感谢订阅小专栏的这十来个人,因为你们的支持,我倍感荣幸,几乎没啥知名度的我,竟然有人愿意付费看我的专栏,并且目前的文章都是公开发表的,也谈不上所谓的付费阅读,也许你们只是单纯的支持吧。

有人支持,固然是好事,如果放任自己,不持续更新内容,就有点说不过去了。

小专栏上目前的内容,几乎都是在博客写完之后,贴过来的,没有独家内容,目前看来,似乎不太合适,但如果相信我,我会让它产生长期的价值。


好了,说了这么多,谈一下近期关于产出内容的计划,根据上面那篇文章里提到 2020 年要做的事情。我计划开始输出教程(也谈不上教程,主要是一些思考与总结)了,与开发设计的工作同步进行。

第一个输出

关于后台数据服务这块的开发,我基本完成了,接下来就是输出总结了,文章目录我已经整理完成了,如下图:

后台数据服务

从这个输出里,你可以大概了解使用 Node.js 开发一个后台数据服务的全过程,当然了,对技术深度的期待不要过高,因为我只是一个产品经理(嗯,这个借口不错),只是想让你大概了解一下开发这么一个服务的全貌。

如果你也是一名产品经理,且动手能力不错,可以跟着我的内容,开发一个后台 API 服务,能达到这个效果,我就很满意了。

有兴趣的,可以关注一下,分享的内容,我会持续更新在这里,这个可能需要一些时间,写总结总是比写代码要费时间。

如果你不想断断续续的,没关系,全部分享完毕之后,我会导出成一本电子书,到时候再看也不迟。

第二个输出

某一天无意中打开了 Coding 的主页,勾起了我学习产品技术相关的一些回忆,不断回想,不断记录,不知不觉就写了很多内容。

想着索性写成一个合集,就当是自己的回忆录了,标题就叫「我的产品技术之旅」。

说实话,我的产品技术学习之旅,其实一点也不值得参考,而且,我自己学得也很烂,对于你来说,这个内容,其实没有什么价值,你就当故事会看好了(如果想看的话)。

但是,我想要写出来,回忆录嘛,以后自己再回头看的时候,应该挺有意思。前期虽然不咋地,但重点在进步,对吧。

这个内容的目录我也整理出来了,感觉标题起得挺有「故事会」的感觉,哈哈。

我的产品技术之旅

同样,这个内容,我也会陆续在这里发出,希望你不要觉得无聊,不过,看看我的故事,没准你会觉得自己还挺优秀的,增强一下自信心,多好。

好了,内容大概就这些,感谢阅读。

阅读更多

初显成就 —— 静态博客站点

这是《我的产品技术之旅》的系列文章,每篇文章,我都尽量保证它的独立性(不一定按照时间顺序来写),但不可避免会有些前后关联,毕竟这是一个成长的过程。

那天无意中打开了 Coding 的主页,勾起了我的一些回忆。

刚上班那会(2014 年初),Coding 还不叫这个名字,而是叫 Gitcafe,它是国内与 GitHub 类似的一个代码管理平台,提供代码托管服务。

在 GitHub 上线 Pages 的服务后,Gitcafe 也同步上线了类似的服务,那段时间静态博客网站,一度非常的火热,也许现在依然火热,只是我不再关注了而已。

什么是 Pages 服务?Page 服务原本是 GitHub 给一些开源项目提供介绍网站的托管服务,但是,人们发现了它免费托管的「特性」,于是,大家都纷纷用来搭建自己的博客,在本地使用 Markdown 写完文章,通过 Git 工具传输到 GitHub 上,博客站点就自动更新了。同时,它还支持自定义域名,简直是博客羊毛党的福音。

由于 GitHub Pages 在国内的访问速度不是很理想,所以,很多静态博客都采用了双向部署的方式,同时在 Gitcafe 上也弄一份,犹记得那会,我还在折腾 Hexo(一个静态博客框架,基于 Node),折腾了有一段时间,还写了一些关于 Hexo 的文章,现在偶尔还有看到我文章,而加我微信的朋友。

后来,基于 Hexo,我在公司里整了一个静态知识库的站点,把公司的 Word 文档,全部转换成了静态网页,使用 Hexo 顺手就搭了个静态站点,部署在了公司的内网上。由于还会点 Nginx,把 Nginx 当作反向代理服务器,针对不同类型的知识文档,一下子就部署了 4 个 Hexo 服务,每个 Hexo 服务分别使用不同的主题样式,代表不同类别的知识文档,最后 down 了个炫酷的首页模版,把 4 个站点的链接添加上,在 IT 部门同事的帮助下,还整了个公司内部的域名,访问一下,还挺炫酷的。

整个站点就是 4 个 Hexo 的服务,没有写一行代码,仅仅只需要会点 Markdown 以及 HTML 的一些知识就可以了,剩下就是服务器部署的一些东西了。

在做这个事情的时候,最花时间的其实是 Word 转 Markdown 的这一步,上百个文档,我都是一个一个手动复制粘贴调格式转过去的,现在想想当时也是够傻的。不过那会倒是觉得挺有意义,挺有趣的一件事情。

刚接触网站的搭建,就从零快速搭建起一个知识库的站点,想想就觉得挺酷的。

公司那会正在上线 3KS 系统,我在上面新建了一个讨论组,算是给我搭建的这个知识站点做一个小广告吧,居然真的有人来询问我怎么弄的,并说这是整个 3KS 平台最酷的讨论组。听到别人这样的赞许,我还是很激动的。别的帖子都是在 3KS 上展示的,而我直接给了个链接,跳转到我的 Hexo 站点,第一眼在颜值上就胜出了。

做的这个事情,直属领导还是比较看好的,还给我申请了一个小项目,记得最后发了几百块钱的项目奖金。当然,做这个事情,并不是为了申请什么项目奖金,更多的是为了提升自己的工作效率,这一个点几乎贯穿了,我今后做的所有关于产品技术的事情。

这个项目带来的最大优势,是提升了查看旧文档的效率。学习业务相关知识,并不像学习技术那么单纯,很多时候,我们需要不停的查看历史的文档资料,而这个检索过程,就比较痛苦了,历史文档都是 word 需要一个 word 一个 word 的打开,而现在打开一个网址就可搞定了,剩下的就是浏览网页了。

但是,这个项目有一个致命的缺点,那就是更新文档的流程,显得太过于技术范了,首先需要会使用 Markdown 来写文档,另一个就是使用 Hexo 的一些命令,才能将本地文档传到服务器中。

对于我来说,这个过程可能很简单,但是,对于不知道什么是 Git,什么是 Hexo,甚至不知道什么是 Markdown 的其它同事来说,这个入门门槛就有点高了。

而如果同事们依然使用 word 来写,我再将他们写的 word 转成 Markdown,并上传到服务器上,这个工作对于我来说,就有点负担了。

中间我有想过,写一些批处理的脚本,或是干脆开发一个管理后台,来自动化处理这个问题,但由于一些原因,迟迟没有去做,毕竟这对于我,或对于部门来说,都只是一个业余的事情。

在我离开这个部门之后,不出意料,这个站点的文章就再也没有更新过了,也许现在还能够在内网上访问,但最新文档的发布日期,应该永远停留在了几年前。

后来,这个部门的领导也换了,记得新的领导后来还电话问过我,这个站点要如何重新更新起来,我心想,一时半会,我也给她讲不明白,况且还有一些问题不好解决,就让她放弃了,表示「没人了解这块,不太好弄,重新花时间整理这个,不太值得,况且公司也陆续上线了 3KS 和 KM 系统,直接使用这些专业的知识管理系统就可以了」。

这应该是我在公司做过的第一件,自己感觉略有成就的一件事情,然而却是岗位职责之外,冥冥之中,似乎预示着什么。

阅读更多

2020 接下来要做的一些事情

有一个月的时间没有发布文章了,并不代表我没有输出,相反,这一个月,我输出得更多了。

给自己定了一个短期的目标,就是要做一款 App,计划在今年年底上线,说起来似乎很简单的样子,对于有相关开发经验的人来说,可能真的很简单,可是,对我来说,其实没有那么容易。

做一款完整的 App,从思路到设计到开发,中间要经历很多的环节,而其中的很多环节,我现有的知识储备是不足以支撑的。

所以,我需要一边学习,一边去尝试做这个事情。并且,很多内容,我都是零基础的,例如:设计,iOS 开发等等。

为什么要做这件事?

去年的时候,我就给自己定下了一个目标,未来的职业目标:自由职业。

做这个事情,并没有想象中的那么容易,这句话并不是随口说出,而是亲身经历过的。

当时,一厢情愿的认为,有了独立的时间,就能做好这个事情,现实毫不犹豫的给了我一个响亮的耳光,让我发现,无论是内外的(自律)还是外在的(能力),我都没有准备好,甚至差得好远好远。

没有做任何的准备和调研,就轻易的「下海」,没淹死已是万幸。「上岸」之后,思考自己的问题所在,其结论实在令人惭愧。

最大的困难,并不是外在的,而是内在的。自己的执行力以及自律,实在太差。在公司上班的时候,很难发觉到,因为在公司上班,有规律的作息时间,有上级领导或是 KPI 在推着你往前走。

而一旦失去了这个推力,你是在倒退呢,还是原地不动,还是能够继续往前走呢?这是个很大的考验。它考验的是你内在的自律。

对于一个自由职业者来说,这是最最最基本的要求,而我显然还不具备。

现在我又回到了职场,一方面为了解决燃眉之急,另一方面,我要为心中理想,做好必要的准备。

上线一款 App,可能并没有什么用,但是做这个事情的过程,就是在训练自己自律的能力,让自己能够去接触新的知识,学习它,反复的发现问题,解决问题,使自己跑动起来,并养成习惯,形成肌肉记忆。

接下来做什么?

去年在家的时候,做了一款微信小程序「字节加工厂」,根据自己的需求,做了一些小工具,其中有几个工具,我自己一直在使用,对我来说,它是有价值的。

可是,受限于微信小程序的平台,给我的开发以及使用体验都不是很好,我计划重新设计整体的架构。

最基本的要求是前后端分离,单独把后台服务拿出来,提供数据 API,所有的客户端统一走一套后台服务,这样前台就比较灵活了,可以做不同平台的扩展,小程序只是其中一个,这样就不必受限于小程序平台了。

后台服务程序将按照服务多个工具的场景来搭建,也就是「字节加工厂」的统一后台,需要考虑后续工具的扩展。

总的来说,要做的这个事情,并非是一个 App 那么简单,分为两个维度来看。

一个维度是,不同工具的开发,「字节加工厂」原本就是定位为工具合集,所以,每一个工具都应该有前台和后台。

另一个维度是,工具在不同平台的开发,后台数据统一,但前台会提供多个平台的客户端。

所以,要做的事情还是很多的。

今年的计划

今年暂且只是考虑把「记支出」这个工具跑通,包括的内容有:后台服务(记支出)、Web 端、小程序端,iOS 端,以及 Andriod 端。

由于之前有过开发经验,小程序和 Web 端应该相对比较简单,主要精力在后台服务程序以及 iOS/Andriod 端的开发,iOS/Andriod 端完全从 0 开始,iOS 端计划自己来做,Andriod 端大概率会拜托别人帮忙实现。

这样的安排可能还在可控范围之内,不至于特别心虚,大致的时间规划如下:

这个计划只是大概的一个时间点,因为很多内容要同时进行,比如 iOS 开发的学习,从现在就要开始了,等前面做完再开始,估计就来不及了。

其实这个计划时间排得都比较宽松,因为我要在业余的时间去完成这些事情,这是一个自我学习的过程,并不会产生实际的收益,甚至会付出必要的成本(服务器相关)。

当业余做的这些事情,哪一天能够产生收益的时候,也许预示着我已经准备好了,就可以期待下一次的任性了。

最后

整个事情的时间维度有点长,要做的事情也很多,中间我会分享一些进展以及遇到的一些问题,同时,我也会整理相关的开发教程,我希望有一个单独的地方来记录这些事情。

之前在做小程序的时候,创建了一个免费的知识星球,在上面发布了一个小程序开发的入门教程,有一些朋友加了进来,这次就还用这个星球作为分享交流的载体,也欢迎大家在上面讨论。

谢谢。

阅读更多

至海波 - 写给大佬的一封信

海波,你好,谢谢你的回复。

其实很早之前就想给你写邮件来着,去年年中的时候,有一段时间比较困惑,原本想要在你这里寻求一些建议,然而,写了一半,发现很多困惑,多数是惰性所为,想得太多,做得太少。写给你不过是想寻求安慰罢了,似乎也没有必要写了。

就像我问你 iOS 如何入门一样,在网上顺便一搜,大致就知道学习路径了。剩下的就是去实践的问题了,不断的去写代码,发现问题,解决问题。

自己所欠缺的仅仅是执行力,这个我想任何人都没有办法能够帮到自己,唯有自己去克服。

对你最初的印象,还是最开始在使用 Farbox 的时候,看到你写的那些介绍产品的相关文字,觉得很有个性,在其它地方很难看到这样的态度。

再后来,了解到你一个人就做出来了这么多的产品,这执行力着实让我倾佩,后来就一直关注你和你的产品了,MarkEditor 是我第一款在 Windows 上购买的软件,那会还是 1.0 版本,那时自己还没有 MacBook,再后来到 MarkEditor 2.0 以及目前的全端。

我有时会想,为什么能够一路跟过来,是因为你的产品吗?后来觉得并不是,恰恰相反,正是由于你本身,或是执行力,或是做事的态度,让我注意到了你的产品。(说得好像跟表白似的)

我是一个挺没有存在感的人,各方面都挺中庸,但是,似乎运气一直还算不错,毕业之后,进入了一家国有企业上班,工作一直属于中上游那种状态,不是很出彩,但是也还不赖。

但是,我心中又一直不满于现状,在公司里看不惯很多事情,可是感觉又没有能力去改变什么,到后来也不想去改变什么。

直到去年年初,我辞职了待了5年多的公司,可能你看过我写的那篇文章,那段时间一直在想,我可能并不适合上班,也想通过自身的手艺去做一些事情,能维持基本收入就行。

于是,自由职业成为了我的目标,我觉得这样很酷,但很明显,我把这个事情考虑得太简单了,离开公司后的压力,远比上班拿工资要大得多,而且,我并没有做好准备,只是自己的一厢情愿。

这段经历让我清楚的明白,我的能力以及我的决心,并不能支撑我的梦想。我的执行力以及自律性,实在太差,我缺少太多自由职业者应该具备的基本能力。

最终,在去年年末,我还是去上班了,并不是放弃了理想,而是还需要时间准备。

我应该算是最早一批加入全端的学员,印象中似乎没有怎么犹豫就加入了,因为我想成为像你这样的独创者,我并没有对课程抱有特别大的期待,因为我知道不管学习什么,除了孤独痛苦的付出,别无他法,哪怕你的教程写得再优秀,学习者一样需要经历这个过程,再好的老师,也无法代替学生去经历这个过程。

不过,从你的教程里能看出来,你一直在强调自驱性学习,也是想要尽早告诉我们这个道理,这个可能才是最有价值的。很多内容提个点,剩下的还得我们自己去经历,唯有经历过,才有可能成长。

再后来,从你推送的文章中,我慢慢发现,很多时候你似乎也很矛盾,对于产品也很纠结,对用户需求的把握同样模糊不定。但是,你却一直在尝试往前走,做新的产品(MiniTodo & Markdown.app),给我们写新的教程,甚至是学习新的知识(SwiftUI),说实话,我很受启发,也更加的钦佩。

我缺少的可能就是这份坚持与执着,何必在乎前方的路好不好走,按照自己的方向朝着目标走就行了,终归会走到终点的。

最后,谢谢你和你的产品,这么多年的陪伴,当然很高兴能让你进一步认识我。

谢谢。

阅读更多

如何从小白变成大 V

这是去年年初从公司离职后不久写的一段文字。

那段时间,总是妄想着,怎么快速从小白变成大 V,但是,你知道的,这是不现实的,不符合能量守恒定律。

因为从来就没有轻而易举的成功,更别说是毫无背景的小白了。

道理都明白,只是实践的过程是漫长且艰辛的,自己在这条路上走得很慢很慢,那天写完这段文字之后,就放着了。

将近一年过去了,再来看看这段文字,说实话,有点惭愧,因为我连第一步都还没有走出去。

1. 获得某一领域的核心竞争力

每个人都有擅长的领域,但是具备核心竞争力却不容易。

网红那么多,出名的也就那么几个,如果你稍微了解一下,较出名的那些,都是有过人之处的,这就是核心竞争力。

获得某一领域的核心竞争力,除了刻意练习,别无他法。要是说捷径,那么就找你兴趣所在的领域。

现在的你擅长什么,喜欢做什么,坚持做下去就行了。

直到在这个领域里,达到专家水平。这里需要注意的是,领域重在深度,而不是宽度。

2. 形成对他人有价值的产品

对于大部分人来说,获得核心竞争力,其实并不是最难的。难的是,如何将自己的核心竞争力,形成能够对他人产生价值的产品。

这里的产品泛指对外的输出。

你说你喜欢唱歌,唱得又好,假如你不去参加歌唱比赛,不在音乐平台发布自己的歌曲,连网络直播间也没有,甚至都不把自己的歌曲录下来分享出去,你唱得再好听,除了能在 KTV 上自嗨下,又有什么用呢?

将自己的核心竞争力,形成对他人有价值的产品,这是关键的一步。

假如你不能给他人创造价值,又有谁愿意给你买单呢?

一篇文章是否有人打赏,取决于它是否对人产生了价值,并不取决于这篇文章的文采。

3. 推广产品,持续积累,形成正反馈

推广这个词,可能有点投机取巧的意思,你可能会说,只要产品足够优秀,根本不需要刻意去做推销。

话虽如此,但是靠自身能力获得的增长是有一定局限性的,微信尚且需要借助春节的活动去做营销推广,更何况你我的产品呢。

所以,适当在自己的社交圈里,做一下产品推广是很有必要的,切忌投入过多的精力,因为持续积累及打造产品才是立根之本。

完。

阅读更多

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

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

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

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

目录

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

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

什么是微服务

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

正是由于当前技术方案已经不能满足业务需求,我们才会去研究新的技术方案,于是,就会出现一堆新的技术名词。什么负载均衡,什么 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 啊,微服务这个话题有点深。


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

阅读更多