自媒体的发展以及内容生产者的应对

自媒体的发展以及内容生产者的应对

閱讀本文約花費: 9 (分鐘)简介 自媒体是媒体的范畴,它的出现与发展和互联网息息相关。它促进了媒体行业的发展,诞生了一批知名自媒体和网红,催生了新的经济形态。 2003年7月,美国新闻学会媒体中心发布了由谢因波曼与克里斯威理斯两位联合提出的“We Media(自媒体)”研究报告,里面对“We Media”做了十分严谨的定义:“We Media是普通大众经由数字科技强化、与全球知识体系相连之后,一种开始理解普通大众如何提供与分享他们自身的事实、新闻的途径。” 作为媒体,它包括内容生产者、传播媒介和受众。内容生产者包括个人、组织、机构,媒介包括论坛/BBS、Facebook、博客、Twitter、微博等,比较专业和规模化的媒介平台有微信公众号、头条号、UC大鱼号、百家号。 发展历程 传播媒介的发展 图书、杂志、报纸等传统媒体,期间诞生了知名图书作者、编辑和媒体人,如韩寒、梁文道。 论坛、BBS社区,多数是区域性、垂直领域的,传播范围主要在垂直领域和地方。 Facebook、Twitter、博客、微博。借助互联网技术和人口红利,自媒体人的影响力开始扩大,粉丝数、转发量、互动数显著增加。出现了有影响力的自媒体。 成熟的自媒体平台,微信公众号、头条号、UC大鱼号、百度百家号。 内容生产者的发展 从早期的个人和专业媒体到现在个人与专业组织机构并举。 特点 与互联网紧密结合。互联网的发展推动了…

Read More Read More

那些“月入十万”的自媒体人,你们还好吗?

那些“月入十万”的自媒体人,你们还好吗?

閱讀本文約花費: 12 (分鐘)编者按:本文来自微信公众号“科技不谓侠”(ID:Beaman303), 1 就像上知乎的朋友,总给人一种人均985本硕、人均年薪百万的错觉。 身在自媒体圈子的很多朋友,也总有一种自己可以轻松月入十万的假象,而且还是税后的~ “月入十万”是存在的,甚至“月入百万”也不是不可能,但只是这个行业金字塔尖的那些。 然而今年对所有的自媒体而言实在不友好:一场新冠疫情来得措手不及,经济下行之下,甲方金主爸爸们纷纷缩减预算,总盘子变小了,预算会更加优先倾向头部。 8位数变成7位数,7位数变成6位数,随之而来的则是自媒体人“月入十万”梦想的大批量破灭。 “这个阶段的自媒体红利早已过去”——这句话已经喊了好几年,但一直以来还是有大量的人挤破脑袋往里冲,只是因为“已经过去”完全没有一个明显的界限,而实际上这个界限是跟着发展阶段同步变化的。 不谓侠倾向于把自媒体行业发展划分为三个阶段: 1.0阶段:博客、微博、微信公众号爆发,平台全面红利期,只要下手早,敢于动手,内容搞起来,粉丝追着跑; 2.0阶段:“两微一端”,虽然平台规则趋紧,但大环境尚可,红利尚未散尽。原创、打造IP成趋势; 3.0阶段:监管强度大,平台规则严,基础设施进一步完善,视频开始大放异彩。 目前自媒体行业总体上缺乏全新的增长点,甚至是疲软的,更残酷的现实是:大者恒大,小者更小。 大量成功案例也吸引着许多年…

Read More Read More

在首席架构师手里,应用架构如此设计

在首席架构师手里,应用架构如此设计

閱讀本文約花費: 25 (分鐘) 无架构,不系统,架构是大型系统的关键。从形上看,架构是系统的骨架,支撑和链接各个部分;从神上看,架构是系统的灵魂,深刻体现业务本质。架构可细分为业务架构、应用架构、技术架构,业务架构是战略,应用架构是战术,技术架构是装备。其中应用架构承上启下,一方面承接业务架构的落地,另一方面影响技术选型。如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题。本文基于作者在大型互联网系统的实践和思考,和大家一起探讨应用架构的选型。本文主要内容包括:应用架构本质单体式分布式SOA架构SOA落地方式应用架构进化应用架构本质应用作为独立可部署的单元,为系统划分了明确的边界,深刻影响系统功能组织、代码开发、部署和运维等各方面,应用架构定义系统有哪些应用、以及应用之间如何分工和合作。分有两种方式,一种是水平分,按照功能处理顺序划分应用,比如把系统分为web前端/中间服务/后台任务,这是面向业务深度的划分。另一种是垂直分,按照不同的业务类型划分应用,比如进销存系统可以划分为三个独立的应用,这是面向业务广度的划分。应用的合反映应用之间如何协作,共同完成复杂的业务case,主要体现在应用之间的通讯机制和数据格式,通讯机制可以是同步调用/异步消息/共享DB访问等,数据格式可以是文本/XML/JSON/二进制等。应…

Read More Read More

WordPress文章和页面的区别

WordPress文章和页面的区别

閱讀本文約花費: 4 (分鐘)默认情况下,Wordpress提供了2种方式供我们写作内容,文章和页面,虽然说两者外观上并没有什么区别,但是从其他方面来说,还是有很多不同的,在为网站添加内容时,文章和页面的选择也非常重要 如果你是刚刚接触Wordpress的朋友,对于哪些内容该使用页面,哪些内容使用文章是非常困惑的,所以为了帮助大家更清晰的了解文章和页面的使用情景,本文将详细介绍WordPress中文章和页面的区别 WordPress文章和页面的差异 – 时间 WordPress文章有具体的发布日期,一般会显示在文章的标签上,如果你打算写一个非常普通的文章,比如博客、记录之类的,你应该使用文章。 WordPress页面则并不会显示发布日期,大多数的页面内容并不会受时间的影响,非常常见的2种页面就是联系页面和关于页面,这是我们希望用户随时都能看到的内容,并且长期有效 首页展示 如果你是采用的WordPress默认的博客布局,也就是首页显示最新文章,你会发现所有新发布的文章都会展示在首页,而页面则不会展示在首页,页面默认情况下是不会被人发现的,除非你将把它添加到菜单,或者用链接指向它 这里我们可以用它的特性做一些特别的页面,比如你可以创建一个独立页面,只想要特定的人访问,单独发给它们链接,不在首页放入口 页面和文章的组织:分类、标签和子页面 当你创建一篇博文时,你可以选择添加分类、标签 …

Read More Read More

[BetterExplained]书写是为了更好的思考

[BetterExplained]书写是为了更好的思考

閱讀本文約花費: 8 (分鐘)我经常在走路和睡前总结所学过的内容,思考遗留的问题,一段时间的阅读和思考之后,一个总体的知识框架就会逐渐浮现在脑海中。然后我会将它书写下来,然而,我往往非常惊讶地发现,当我书写的时候,新的内容仍然源源不断的冒出来,就像我的键盘自己也会思考一样。 大半年前的时候,我曾在一篇文章《跟波利亚学解题》中写到将问题求解的思维过程记录下来的好处,现在再次回忆起来,当时列出的几点其实不仅对于问题求解是大有好处,对于平时的思考也是同样的道理。 书写的好处有以下几点: 书写是对思维的备忘:人在思考一个问题的时候,就像是在黑暗中打着电筒往前走(事实上,我们的工作记忆资源是有限的,有研究证明我们只能在工作记忆里面持有7加减2个项目;此外认知负荷也是有极限的),每一步推导都将我们往前挪一小步,然而电筒的光亮能照到的范围是有限的,我们走了几步发现后面又黑了,想到后面就忘了前面的,想到某个分支上去就忘了另一个分支,我们常常想着想着就想岔了,想岔了也就罢了,问题是一旦想岔了太远,就很难回到当初岔开的地方了。有时候,我们是如此努力地试图一下就走出很远,同时又老是怕忘记目前已经取得的进展和重要结论,结果意识的微光就在一个很小的范围内打转,始终无法往前走出很远。而将思维过程记录下来,则给了我们完全的回溯自己的思维轨迹的可能。举个具体的例子,平时面对一个问题我们常常首先会想出几个主要的、关…

Read More Read More

设计中的 9 个关键状态

设计中的 9 个关键状态

閱讀本文約花費: 7 (分鐘)这篇文章介绍了 初始,载入,和 空 等设计中的 9 个关键状态。通过将这些设计状态引入设计/开发流程,我们在设计/开发更会主动的为用户着想,我们的产品将会更贴近用户,从而具有更强的竞争力。 缘起 这次回国,我见到不少在创业的朋友,也把玩了他们的产品(绝大多数是手机应用),并为他们的产品提供各种建议。经过交流,我发现他们的产品有一个通病:只考虑理想状态(happy path),而忽视其它状态(unhappy path)。 这么说比较抽象,我举几个例子: 某购物推荐应用,我在注册之后进入应用主界面,这时推荐列表是空的(因为用户还没有选择任何偏好) 某订饭应用,我完成订单后没有任何提示,直到经过一番点击,我才意识到已下的订单在另外一个页面里 某新闻应用,我在注册时输入密码,点击确认,没有任何反应,询问应用开发者之后才直到密码不能少于 8 位 总而言之,这些交互问题都是只考虑理想状态而导致的。按理说这些问题在测试时就应该被发现,但为什么没有被发现呢?我观察了下他们的测试流程: 安装应用 注册,登录,填一些数据 各种测试 这时你可能已经发现问题了——开发者和测试者都对产品很熟悉,因此他们跳过了第 2 步(注册,登录,填一些数据)直接进入第 3 步进行测试,这就导致了第 2 步中的问题很难被发现。然而第 2 步至关重要,因为如果注册有…

Read More Read More

Service Mesh 在有赞的实践与发展

Service Mesh 在有赞的实践与发展

閱讀本文約花費: 20 (分鐘)一、缘起 有赞初期,使用的是 Nginx+PHP-FPM,所有的业务逻辑代码都在一个叫做 Iron 的 PHP 代码仓库里,是一个典型的单体应用 (Monolith),整体架构可以简单的表示成下图: 架构在有赞初期,团队规模比较小,且业务逻辑相对比较简单的时候,很好的支撑和承载了有赞的核心业务。但是,随着有赞业务和团队规模的极速发展,单体应用的缺陷愈来愈凸显: 耦合性高 隔离性差 团队协作性差 一次发布带来的故障往往需要几个业务团队的人坐在一起,花费数十分钟甚至几个小时才能定位究竟是哪处改动引发的。对单体应用进行微服务改造,势在必行。 综合当时团队和业务发展的实际情况,一方面,有赞选择了国内非常流行且具备良好生态的 dubbo 作为 Java 语言 RPC 框架;另一方面,考虑到团队中有相当数量 PHP 开发的同学,有赞内部孵化出了 ZanPHP——使用 PHP 语言的纯异步 RPC 框架,并选择了 ETCD 作为服务注册和发现中心,开始搭建有赞服务化的整体架构。为了解决跨语言 (Java 与 PHP 语言之间) 的 RPC 通信问题,有赞在 facebook 开源的 thrift 协议基础上进行了二次封装,开发了 NOVA 协议用以支持跨语言 RPC 调用。 综上所述,这一时期,整体的架构选型如下: 尽管将单体应用拆分成微服务能够带来一系列众所周知…

Read More Read More

我在南大的七年

我在南大的七年

閱讀本文約花費: 25 (分鐘)—— 跨进南大校门的第一天,我知道,我自由了。 父亲是个对新事物有强烈兴趣的人,村里第一台电视机是他自己组装的,当时全村人都跑过去看,电视机只能收到一个台,CCTV。座机电话是第一个装的。大哥大刚出现的时候,他也是第一个买来用的,那个时候的移动电话真是贵得离谱。 父亲告诉我的第二件最重要的事情是:遇到任何问题,找书去就行。他在自己的专业中完全是自学的。在不属于自己的专业中(后来买了电脑之后需要学习如何架设公司网站,如何网上营销,如何进行电子财务管理,如何使用各种作图软件制图等等)也全都是靠买书自学。 为什么说到这两件事情,因为这是对我一生影响最重大的两个习惯。第一个习惯给了我学习新东西的强烈动机,有了热忱和兴趣,做事情就不觉得累,就自得其乐。第二个习惯则给了我学习任何新东西的方法——不会么?查书去。(当然,学习一门专业并不完全通过看书就行,但这毫无疑问是至关重要的一个途径。) 高三的时候,父亲买了电脑,我立时对这个神奇的事物产生了强烈的兴趣,每期的《电脑爱好者》和《电脑报》都会买来细细看,有时看到各种小工具、技巧还会摘抄下来,回去在自己家里的机器上捣鼓。那个时候我并不知道这样单纯的兴趣会把我引向一条专业的程序员道路。 高三时间变得越来越紧,分配给兴趣的时间越来越少,但兴趣的火花一直都没有熄灭。 跨进南大校门的第一天,我知道,我自由了。 这个自由并不是…

Read More Read More

9个offer,12家公司,35场面试,从微软到谷歌,应届计算机毕业生的2012求职之路

9个offer,12家公司,35场面试,从微软到谷歌,应届计算机毕业生的2012求职之路

閱讀本文約花費: 48 (分鐘)1,简介 毕业答辩搞定,总算可以闲一段时间,把这段求职经历写出来,也作为之前三个半月的求职的回顾。  首先说说我拿到的offer情况: 微软,3面->终面,搞定 百度,3面->终面,口头offer 搜狗,2面,悲剧 腾讯,1面,悲剧 布丁移动,3面,搞定 涂鸦游戏,3面,搞定 友盟,3面->CEO面,搞定 雅虎,4面->终面,搞定 微策略,2面,悲剧 人民搜索,3面->终面,搞定 人人,2面+终面+Special面,搞定 Google,7面,搞定 求职经历分为定位、准备、简历、笔试和面试这五个部分,大家挑感兴趣的看就成。 我的求职经历适用但不限于码农,不适用与企事业单位(据说是完全不同的考察标准和流程)。废话比较多,大家耐心忍受,有什么问题可以跟帖提问。 2,定位 教育经历:本科在大连某工科院校,由于GPA比较惨烈+挂科,所以没保成研,毕业后修了一年英语双学位,然后到帝都计算机职业教育学院接受再教育。 技术能力:属于半码农半产品的类型,代码编的过去(搞过compiler),也有一些拿的出手的产品(几十w的用户量),一句话描述:几十w代码+几十w用户的Coder。 专业能力:非ACM出身,算法拙计但基础扎实。由于单身所以看了N多书(CS+心理+经管+历史),扯淡能力强大,碰到非专业的各种秒杀,碰到专业各种拙计。 …

Read More Read More

架构设计-谈谈架构

架构设计-谈谈架构

閱讀本文約花費: 32 (分鐘) 本文首先介绍了架构的概念定义,并介绍如何针对当前需求,选择合适的应用架构,希望对您的学习有所帮助。 1、什么是架构和架构本质 在软件行业,对于什么是架构,都有很多的争论,每个人都有自己的理解。 此君说的架构和彼君理解的架构未必是一回事。因此我们在讨论架构之前,我们先讨论架构的概念定义,概念是人认识这个世界的基础,并用来沟通的手段,如果对架构概念理解不一样,那沟通起来自然不顺畅。 Linux有架构,MySQL有架构,JVM也有架构,使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构,应该关注哪一个?想要清楚以上问题需要梳理几个有关系又相似的概念:系统与子系统、模块与组建、框架与架构: 一、系统与子系统 系统:泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能独立完成的工作能力的群体。 子系统:也是由一群关联的个体组成的系统,多半是在更大的系统中的一部分。 二、模块与组件 都是系统的组成部分,从不同角度拆分系统而已。模块是逻辑单元,组件是物理单元。 模块就是从逻辑上将系统分解, 即分而治之, 将复杂问题简单化。模块的粒度可大可小, 可以是系统,几个子系统、某个服务,函数, 类,方法、 功能块等等。 组件可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。 三、框架与架构 框架是组件实现的规…

Read More Read More

RFD(反射型文件下载)漏洞原理及实战案例全汇总

RFD(反射型文件下载)漏洞原理及实战案例全汇总

閱讀本文約花費: 4 (分鐘) 1、概念 RFD,即Reflected File Download反射型文件下载漏洞,是一个2014年来自BlackHat的漏洞。这个漏洞在原理上类似XSS,在危害上类似DDE:攻击者可以通过一个URL地址使用户下载一个恶意文件,从而危害用户的终端PC。 这个漏洞很罕见,大多数公司会认为它是一个需要结合社工的低危漏洞,但微软,雅虎,eBay,PayPal和其他许多公司认为这是一个中危漏洞。 2、漏洞原理 先从一个实例理解RFD漏洞,如Google搜索的返回包是json格式:  可见我们的输入在返回包处反射输出,如果输入payload”||calc||,返回: 到这仍没什么问题,但如果我们尝试在命令行里运行这个回显内容,如 {“result”:[“q”,”rfd”||calc||”,”jayway”]}   发现在显示“文件名或目录不存在”的同时,会执行我们的管道符后的命令calc,弹出计算器。解析过程实际为:  所以和DDE的攻击方法类似,我们最终要是让回显内容作为一个bat文件下载,这可以通过分号;或结合社会工程的方式实现: 注:URL中分号;是个保留字符,类似连接符,现已废除。 3、漏洞挖掘 根据漏洞触发的三个…

Read More Read More

微服务运维减负:Istio Service Mesh原理+实战

微服务运维减负:Istio Service Mesh原理+实战

閱讀本文約花費: 8 (分鐘)一、Istio的来源 随着微服务架构的普及,越来越多的应用已经拆分成了微服务的架构。而微服务架构落地的一个难点,就是如何让服务和服务之间进行稳定的通信。 部署微服务之后,如何做服务的负载均衡、容错性、服务监控、日志追踪以及熔断等功能都需要考虑周全。 还好,现在已经有很多开源工具帮你做这样的事情。例如: Netflix的Eureka实现服务注册,它的优势在于实现跨数据中心的服务注册; Ribbon – 客户端的负载均衡; Hystrix – 微服务的熔断器; Zipkin – 分布式的追踪组件; Prometheus – 监控组件; Grafana – 数据可视化的工具; 于是,在写完我的微服务之后,我引入了更多的组件,带来了极大的部署复杂度,每个组件都需要高可用、负载均衡、熔断、日志收集等等。 为了让业务团队返璞归真,将所有精力集中在业务代码而不是配合微服务组件写大量非功能性需求的代码,Istio应运而生。 Istio是谷歌、IBM、Lyft等公司贡献的开源Service Mesh组件。它实现的目标就是让业务开发不再关注微服务之间如何调用、管理、监控等非功能性需求,而是让Istio来处理这些问题。Istio和Kubernetes有天然的支持。 Istio能轻松解决蓝绿发布和金丝雀发布的问题。 金丝雀发布有什么用?它的最大实际意义,是让运维不用在夜里加班…

Read More Read More

到底什么是数据中台?

到底什么是数据中台?

閱讀本文約花費: 35 (分鐘) 文章中作者主要围绕数据中台是什么?普通企业该不该做数据中台?数据中台会带来怎样的挑战等问题谈了谈自己的看法。 导读:数据中台被誉为大数据的下一站,由阿里兴起,核心思想是数据共享,并在 2018 年因为“腾讯数据中台论”再度成为了人们谈论的焦点。如今似乎人人都在提数据中台,但却不是所有人都清楚数据中台到底意味着什么。数据中台是只有大厂才需要考虑的高大上的概念吗?普通企业该不该做数据中台?数据中台的出现会给现有数据从业者们带来颠覆式的挑战吗?带着上述问题,谈谈他对于数据中台的看法。 数据中台不是大数据平台! 首先它不是一个平台,也不是一个系统,如果有厂商说他们有个数据中台卖给你,对不起,它是个骗子。 要回答数据中台是什么,首先要探讨一下中台到底是什么。虽然没有明确的定义,但是作为理工直男,我们可以先把中台看作是一种中间层。既然是一种中间层,那么中台确实是一种十足技术用语,我们可以完全从技术角度来探讨了。 我们可以应用 Gartner 的 Pace Layer 来理解为什么要有中间层,这样可以更好地理解中台的定位和价值。Pace Layer 里提到,可以按照事物变化的速度来分层,这样可以逐层分析并设计合理的边界与服务。 在数据开发中,核心数据模型的变化是相对缓慢的,同时,对数据进行维护的工作量也非常大;但业务创新的速度、对数据提出的需求的变化,是非常快速…

Read More Read More

平安付公司壹钱包APP出故障 男子获利千万被判11年

平安付公司壹钱包APP出故障 男子获利千万被判11年

閱讀本文約花費: 11 (分鐘) 原标题:金融理财APP出故障 男子获利千万判11年 叶榅飞一审判决书。受访者供图叶榅飞一审判决书。受访者供图   律师吴绍平回忆,会面时,叶榅飞始终在问:欠钱还了就好了,真的要被判刑?   叶榅飞是福建人,在上海生活多年。去年6月,在使用一款名为“壹钱包”的金融理财软件时,叶榅飞发现,存入的钱被退回银行卡内,但软件上的账户余额却相应增加。此后8天,叶榅飞利用这一故障,前后转账超过350次,套现1125万元。   “壹钱包”平台运营方报警后,叶榅飞被警方拘留。近日,叶榅飞的辩护律师吴绍平收到该案一审判决,法院以盗窃罪判处叶榅飞有期徒刑11年,并处罚金50万元。叶榅飞妻子昨日接受新京报记者采访时表示,丈夫并非主动侵入系统盗取资金,而是利用产品漏洞牟利,并据此提出上诉。   发现漏洞后转账350余次   8天时间里,叶榅飞转了350多次账,每转一次,就意味着得到一笔“意外之财”。   2015年6月16日,叶榅飞下载了理财软件“壹钱包”,并注册激活。当年9月10日,叶榅飞用妻子黄丽丽的证件和手机号码,以黄丽丽的名义,办理平安银行(16.070, 0.50, 3.21%)“花漾卡”,并与“壹钱包”账户关联,用于后者的转账和消费。   “壹钱包”客户端由平安付科技服务有限公司(下称平安付公司)推出,花漾卡则是平安付公司与平安银行…

Read More Read More

技术人员的发展之路

技术人员的发展之路

閱讀本文約花費: 26 (分鐘)2012年的时候写过一篇叫《程序算法与人生选择》的文章,我用算法来类比如何做选择,说白了就是怎么去计算,但是并没有讲程序员可以发展的方向有哪些。 所以,就算是有这些所谓的方法论,我们可能对自己的发展还是会很纠结和无所事从,尤其是人到了30岁,这种彷徨和迷惑越来越重。虽然我之前也写过一篇《编程年龄和编程技能》的文章,但是还是有很多做技术的人对于自己能否在年纪大时还能去做技术感到没有信心。我猜测,这其中,最大的问题的是,目前从事技术工作的种种负面的经历(比如经常性的加班,被当成棋子或劳动力等等),让人完全看不到希望和前途,尤其是随着年纪越来越大,对未来的越来越没有信心。 同时,也是因为在GIAC的大会被问到,程序员老了怎么办?而在年底这段时间,也和几个朋友在交流中不断地重复谈到个人发展的这个话题。我的人生过半,活到“不惑”的年纪,自然经常性的对什么事都会回头看看总结归纳,所以,在交谈过程中和交谈过后,自己也有一些思考想记录下来。因为我本人也是在这条路上的人,所以,谈不上给他人指导,我同样也是在瞎乱折腾同样每天在思考自己要去哪儿的“一尘世间迷途老生”。况且,我的经历和眼界非常有限,因此,下面的这些关于个人发展的文字和思考必然是受我的眼界和经历所局限的。也欢迎大家补充和指正。 这些东西不一定对,也不一定就是全部,期许可以让你在年底的时候有所思考,在明年的时候…

Read More Read More

Service Mesh的本质、价值和应用探索

Service Mesh的本质、价值和应用探索

閱讀本文約花費: 17 (分鐘)Service Mesh 进入国内技术社区后很快就成了微服务的“新秀”。2018 年 Service Mesh 这一技术可以用“火爆”一词去形容:Istio 1.0 正式发布、Linkerd 2.0 发布、Knative 基于 Istio 打造等等。 网上介绍 Service Mesh 的资料不少,但关注这一技术的本质、价值的内容却不多。阿里巴巴高级技术专家李云带领团队在这一领域探索的过程中想清楚了这两点,并在 QCon 2018 上海站分享了阿里巴巴对 Service Mesh 的探索与实践。 大规模分布式应用的挑战 微服务软件架构(microservices)已经被越来越多的企业作为规模分布式软件开发的首选架构。引入该架构之初是将一个单体应用拆解成多个更小粒度的微服务 (micro-service),通过 HTTP API 或像 Dubbo 这样的 RPC 框架将这些服务组装起来作为整体去提供服务。由于每个微服务足够地小且功能内聚,因此能很好地解决以往单体应用的开发与发布困难的问题。即便如此,随着企业的业务发展和人员规模的壮大,不同业务所形成的微服务群之间的协同却面临新的挑战。 在阿里巴巴内部,RPC 框架由中间件事业部统一开发与维护,以 SDK 形式提供给集团内的其他事业部使用。由于 SDK 与应用逻辑是耦合在同一个进程中的,当 SDK 向前演…

Read More Read More

     
Scroll Up