主页

自我实现 —— Node Web 学习

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

这篇文章开始介绍学习 Node Web 的过程。毕业之前学过 Java 和 Objective-C,但仅仅是学过,并没有产生实际的用处。

后来入职做了一名产品经理,学习了一个新的技术 —— Node,它不是一门新的语言,而只是 JavaScript 语言的运行环境,却帮我解决了很多实际问题。


岗位职责之外,给公司做的那个知识库站点,是第一个跟开发技术相关的项目。虽然不需要很高深的技术,但涉及到的知识点还是比较多的,从前台最基础的网页,到后台服务器的部署,都有涉及。例如:Markdown、Hexo、HTML/CSS/JavaScript、Nginx 以及 Linux 等。

如果完全没接触过这些零散的知识点,还是需要一些时间去了解的。而对于我来说,却比较轻松,因为我更擅长对整个概览的掌握,而不是精专某一个技术点。

做这个事情,让我尝到了一丝的甜头,在部门内,也渐渐有了「技术男」的标签,毕竟我那个岗位是几乎不需要啥技术的。

我在其中找到了「内在价值肯定,外在成就认可」的感觉,满足了我的「尊重需求」,于是,我开始寻求「自我实现」。

重新捡起开发

那段时间,我接触了一个新的开发技术 Node,它是 JavaScript 语言的后台运行环境。它诞生于 2009 年,创立之初,是为了获得一个高性能的 Web 服务器,并提供一套库。

前端由于它的诞生,大放异彩,逐渐发展出了大前端的概念。在我接触 Node 的时候,它就已经很火了。

像之前提到的 Hexo(静态博客框架),就是基于 Node 开发的,虽然 Node 很火,但是与 Java, PHP 等相比,还是显得小众了些。但我觉得很酷。

除了酷,它还有很多优点,例如简洁、开发效率高,使用 Node 开发一个 Web 站点,非常快,写一个 HTTP 服务,只需要短短几行代码就搞定了,简直是全栈开发必学的技能之一。

貌似,全栈开发这个词,就是在 Node 诞生之后,才慢慢火起来的,因为前端开发者常用的 JavaScript 语言,借助 Node 的环境,也可以做后台开发了。

前端工程师可以一个人解决前后端的开发,后来又渐渐出现「大前端」的概念,那个时候,前端真的是火得不行。

在选定 Node 之后,我开始做一些小的系统用来练手,什么需求都做,有时可能是别人的一句抱怨,也有可能是自己 YY 出来的需求,只要有机会,我都去尝试开发,毕竟是学习的过程,不能放过任何练习的机会。

当然,在一个传统的制造企业里,从来就不缺信息化的需求。有那么一段时间,我只要看到某些效率低下的工作方式或流程,我就在想,能不能通过线上协同的方式去提高效率。

练手的那些系统

姑且就叫「系统」吧,虽然大多都只是简单的「增删改查」,根本就称不上所谓的系统,但从这些项目的开发中,我学到了很多东西。

这样的「需求」真的是应接不暇,只是个人精力有限,毕竟还有一堆岗位职责的工作需要去处理。

按照时间顺序,大概分为 3 个阶段:

  • 第一个阶段:练习开发。学会把一些零散的知识点,拼成相对完整的项目;
  • 第二个阶段:解决问题。从单点实际问题出发,规划系统功能,提升效率;
  • 第三个阶段:产品化。从业务流程出发,做信息化平台;

下面介绍第一个阶段:练习阶段。这个阶段开发了 3 个系统,每个系统较之前一个都有很大的进步,这个过程要学习的东西实在太多了。

1. 评分系统

这应该是我使用 Node 开发的第一个 Web 站点,它甚至连最基本的用户管理都没有,但它让我学会了很多基础的概念。例如:

  • 了解了页面模版的概念
  • 学会使用 bootstrap 样式库去搭建页面
  • 学会使用 express 框架作为后台服务
  • 学会使用 Node 访问 MySQL 数据库

这个在部门内用了几周,就没再用了,非常简陋的一个站点,仅仅满足了投票打分的核心需求。

专门找到了当时写的几篇介绍文章:[标签: 评分系统 个人学习](/tags/%E8%AF%84%E5%88%86%E7%B3%BB%E7%BB%9F),读完后,还挺有感触,这就是那时的自己。把时间维度拉长,觉得写作是件非常有意思的事情。

2. 需求收集系统

这是个半成品,甚至都没有部署到线上,只是存在于我的电脑里,在这个项目里,我开始学会使用一些开源的前端组件,例如常用的有:

  • bootstrap-fileupload 上传插件
  • bootstrap-table 表格插件

随着后面系统的开发,使用的第三方库也越来越多,后来,我还专门创建了一个开源项目,用来收集以及总结这些开源组件的使用方法。

GitHub 地址:https://github.com/pengloo53/js-plugin-example

在这个项目的练习上,除了学习组件的使用之外,开始逐渐学习模块化的开发,例如将数据库相关配置独立,再抽象出业务调用数据的模块。

当时也写了几篇介绍文章,只是不完整,就写了 3 篇,[标签: 需求收集系统 个人学习](/tags/%E9%9C%80%E6%B1%82%E6%94%B6%E9%9B%86%E7%B3%BB%E7%BB%9F),这里,大多数精力都花在了前端组件的使用上了。

3. 考核系统

这是我第一个完成程度较高的系统,这个系统的需求不是我自己 YY 的,是我们做客户拜访的时候,领导接回来的。

这原本也不是我们的岗位职责,接这个任务,是因为客户有非常明确的需求,而我们部门恰好又有能力去做这个事情,另一方面,部门领导也想给部门的工作找些亮点。

和前面不一样,这个项目,我只是负责开发,前期的需求沟通是部门另外一个同事做的,还有一个同事帮忙写 SQL,所以,这个项目中,我的角色只是程序员。

经过前面几个系统的练手,做这个项目的时候,还算得心应手,况且我只负责开发,所以,我记得差不多两周的时间,我就完成了所有的开发工作,功能并不复杂,花时间最多的是前端页面布局和样式。

做完这个项目,发现了两个问题,也就是改善点吧。

  • 一个是前端页面太费时间了,如果有现成的页面模板的话,就省事多了
  • 数据库的调用太 Low 了,这个项目的数据库调用都是采用字符串拼接 SQL 的方式

当然也有很大的收获:

  • 了解了完整的项目结构搭建
  • 各种前端第三方组件的学习和使用

不出意外的话,这个项目应该还跑在公司的内网服务器上,相关的业务参数是动态配置的,所以,如果没有大的调整,应该还能跑上一阵子。

学习 Node Web 的过程,就是在这样的状态下,不断的迭代,每开发一个新的系统,都会针对性的解决前面一个系统的问题。

所以,感觉这个过程,还是比较扎实的,我相信,每一个技术的学习都应该是这样的过程,就是不断的练习,练习,再练习。

阅读更多

萌芽之初 —— 认识计算机

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

这篇介绍我那不堪的学业生涯,回忆过去,发现很多事情有因必有果,即便再来一次,也许我依然会走向同样的道路。

计算机专业不就是玩电脑吗

我是计算机硕士毕业的,但我并非科班出身(本科不是计算机专业),在上研究生之前,我对计算机的认识,只是停留在 —— 这专业不就是玩电脑嘛。别笑,真是这样。

大二的时候,才拥有自己的电脑,那是一台联想笔记本,当时预装的是 Windows Vista 操作系统,然而,用了几个月,在还不清楚「操作系统」是个什么概念的时候,我就把它换成了 Windows XP,从此一发不可收拾。

在这台笔记本上,我几乎把所有的系统装了个遍,除了 Windows 的各个版本,还包括 Linux 的各种发行版,从 Ubuntu 到 Federo 到 Debain 到……,这还不算完,后面还整了各种双系统,XP + Ubuntu,Windows 7 + Federo 等等。

这台电脑也因为不堪重负,在上研一的时候,终于被我搞挂掉了,硬盘整出坏道了,后来换了块硬盘,目前扔家里,竟然还能用。

第一台电脑虽然挂了,但是鼓捣系统之心一直没灭,借写论文之由,又买了一台新的笔记本,HP 的超级本(好像当时很火的一个概念),在这台笔记本上,除了联想电脑经历过的那些,还包括:黑苹果,安装上了 xcode,甚至还写了一个 iOS 的 App demo,这个单独再说。

说到这里,关于计算机最初的印象,就是在安装各种版本的操作系统,现在看来,认知不够是多么可怕的事情,浪费了多少美好时光,当时做的那些事情,对现在似乎没有半点实际用处,除了能作为调侃自己的谈资。

我也说不清楚,当时的自己,为什么就是想要去折腾,也许觉得这样很酷,或许是因为对新产品的好奇心,每次发布新版的系统或是软件更新,总是忍不住想要去试一试。

这个经历对于现在来说,没有实际的价值,但是在当时,倒是帮助我做了一个重要的决定,那就是要考计算机专业的研究生,考研的过程虽然辛苦,但不算太难,反正就是看书做题嘛。

即便我有丰富的装系统经历,但是面对那些真正的计算机专业课,也是一脸蒙逼。因为本科是物理专业,考研专业课要考的那 4 本书(计算机组成原理,操作系统,数据结构,计算机网络)都没有正经学过,简直就跟天书一般。

自学这些专业课,跟帖子里教你如何安装系统,完全不是一码事。不过,好在凭着一丝的兴趣,也是硬着头皮看了下去,最后的考试成绩,不算理想,但也没有特别拖后腿,如愿考上了计算机专业的研究生。

终归还是当不了程序员

说来惭愧,上研究生之前,我几乎都没有接触过软件开发,唯一沾点边的是,本科物理专业学过单片机,使用的是汇编语言,这门课是我大学学习生涯里,唯一一个得满分的课程,一度让我觉得「诶,难不成我在编程领域有点天赋,要不深入一下」。

后来倒是自学过 C 语言以及数据库一些知识,兴趣使然,还是很轻松的考过了计算机二级以及三级证书,不过那种程度的编程,完全只是停留在考试层面,都不能算作是软件开发。

真正让我开始接触软件开发,是我的一个研究生同学 LC,他当时给我演示了,他用 Java ME 给自己的功能机写的那个工具软件。那个瞬间,似乎打开了我的一道门,居然还可以给自己手机写软件,这都是我之前想都没有去想过的事情。

于是,我也开始学习 Java,当时,并不是觉得 Java 厉害或真的对编程感兴趣,完全是盲目的学习,觉得能够给自己写软件,是一件很酷的事情,就像之前无数遍安装操作系统一样。

研究生的课程几乎跟写代码没有任何的关系,学的都是基础理论知识,但那时的自己意识不到孰轻孰重,花了大量的时间去学习应用层面的东西,而忽略了基础理论(算法相关)的学习。

现在看来,其实是舍本逐末,就目前来看(已经毕业 6 年了),Java 几乎忘得一干二净,而当时学习的数据挖掘相关算法理论,却是越来越有用,即使对一名产品经理来说,这些基础知识也是异常的重要,因为目前的互联网产品,几乎都离不开诸如聚类、分类以及关联分析的相关算法理论。

这些都是后话了。即便是学习 Java,我也没能深入的扎下去,其中有一个主要的原因:我似乎更倾向于整体概览的了解,而不是某个技术点的深入。这也有可能是我做不了程序员的主要原因吧。

快毕业那会,还学了一段时间的 iOS 开发,而那时没有 Mac 电脑,还整过黑苹果,都不知道我是为了整黑苹果而学习的 iOS 开发呀,还是为了学习 iOS 开发,而整的黑苹果。

在这样的状态下,一不小心就毕业了。毕业之后,成为了一名产品经理,一直至今。

阅读更多

岗位成就 —— 职责之外的探索

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

我的岗位是企业内部产品经理,在这个岗位的本职工作上,很长一段时间,我都找不到所谓的成就感,而在岗位职责之外,却意外发现了一些惊喜。

企业内部产品经理,所负责的产品通常都是企业内部系统,用户是自己人,通常是主营业务的部门。它们会针对自己的实际业务,对企业内部系统提出需求,我们要做的就是去了解它们的实际业务(需求分析),产出系统功能需求文档(PRD),然后在各个部门之间进行协调,在一定的时间内,完成这个事情(项目管理),满足业务需求(产品交付)。

我最初负责的产品是 ERP 系统生产制造业务模块,大多时候的工作都是业务流程梳理,以及系统的业务运维,而一旦熟悉了这块的业务,整个工作流程就显示比较单一且枯燥了。

大公司的业务细分程度通常比较高,如果自己不去寻求改变,或是有所突破的话,很有可能好几年都在一个岗位上,干着重复劳动的工作,身边有太多这样的例子了。

在第二年的时候,我就渐渐感觉到,对这个行业似乎不是很感兴趣,很难深入到业务的根本,有一段时间,我找不到工作的成就感。

从马斯洛的需求层次模型可以看出,现代社会的我们,更需要的是「成长性需求」。

马斯洛需求层次模型

那时的自己应该处在「尊重需求」这一层,也就是「内在价值肯定,外在成就认可」,而这个岗位的本职工作,很难有所谓的外在成就,而其内在价值我也一直没有找到。所以,那时的自己,想要去做不一样的尝试。

最开始提到的,利用静态博客站点的技术,搭建内部知识库,就是自己对「尊重需求」的探索。

这个尝试产生了一些正面的反馈,直属领导的肯定,应该可以算是这个岗位上的成就吧,即便它并非是主要职责工作。

如果直属领导的肯定,只能勉强算作是岗位工作成就的话,那么下面这个事情,肯定算是岗位的成就了。

当时,我们的研发岗位都是聚焦在显示技术领域,而非 IT 信息化,研发岗位的工作有一项重要的 KPI,那就是专利。

我们并不属于研发序列,我们组织的工作,最初的定位,更多充当的是辅助的角色,辅助主营业务做信息化的转型,提升业务效率。

后来集团对信息化的要求越来越高,信息化组织从辅助的角色,慢慢变成领跑的角色,不再是满足业务需求,而是要带领业务,走信息化的道路。其实,这个观念的转变,我们算是起步较晚的了。

对于一线的员工,其实看不出有什么明显的变化,唯一能感受到的是 KPI 添加了一项,那就是要写专利了。

正好那个时间点,我正在鼓捣静态站点的事情,静态站点的优点是无需开发,快速部署,非常适合单方面的展现类网站。但缺点也很明显,页面无法动态更新内容,例如博客中,文章评论等功能就需要借助第三方来实现。

基于对这个事情的琢磨,顺便就写了一篇专利,顺利通过了公司的审核,后来还获得了国家授权,在我离职后,公司的专利专员还在联系我,说在申请美国的专利,需要我确认一些信息,这个对于我来,绝对是意外的惊喜,并且是「名正言顺」的岗位成就,比我做的那些信息化的项目,更加受领导的关注。

我写的那份专利,应该是我们组织有史以来第一份通过国家授权的专利,后来,基于这个思路,我又写了第二篇专利,依然是围绕静态站点的那些问题,提出的一种一体化解决方案,当然前提肯定是在专利网站上查重排除过的。

这篇专利花了我更多的时间和精力,自认为提出的创新点要比第一篇要好,可是,被自己组织内的「专家组」给拒了,被拒原因不详。

随着我们组织专利提交数量的增多,集团的专利部门应对不过来了,于是,我们组织内部成立了「专家组」来做第一层的筛选工作。

所谓的「专家组」并不是专利领域的「专家」,也许他们自己一篇专利也没有写过,还不一定熟悉专利要求呢,却有权利去评价别人的专利是否符合要求,而且还是匿名反馈,感觉这个就有点「社会」了。

被拒之后,我没有去申诉,也没有再重新提交,因为我不清楚哪方面需要修改,再后来,我调岗了,也就把这个事情淡忘了。

在人生第一份岗位上,把应该做专业的主要职责工作,做得有些业余了,却把业余的工作,做出了点成绩,也是一件奇葩的事情。

但是,我依然觉得这是一件值得的事情,重点不是专业和业余的问题,而是你要尽早知道自己的「专业」和「业余」分别是什么。

阅读更多

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

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

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

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

产品经理这个岗位依然很宽泛,单单从面向用户的角度来说,就可分为 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 的兴起,微服务应运而生。

参考文档:


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

阅读更多