Tumblr 扫黄事宜

Tumblr 扫黄事宜

閱讀本文約花費: 13 (分鐘)曾经,tumblr上什么都有 你们知道tumblr吗? 用户层面中的Tumblr,曾经是一个有点杂乱,但是非常自由开放的图片社交平台。 上面会有动漫组放上自己的动画手稿,会有摄影师在上面更新自己新的作品,会有喜欢猫咪的用户在上面每天拍各种各样的萌猫图片,我国几个最大的宠物账号每天发的图,很多都是从Tumblr上面找到的。 猫咪们 动物冷笑话漫画们 其实就是一个普通的图片社交软件,就和如日中天的pinterest以及instagram差不多。 但曾经的Tumblr,对相当大一部分用户来说,其最大的意义不在这些。虽然tumblr上面的猫咪确实很可爱,漫画确实很精美,但它还有一点,是那些如日中天的图片社交软件无法代替的,那就是 黄图 那会儿Tumblr上面有许许多多的小黄图。 高清大图无码,充满艺术性的那种。他们不会和谐平台上的黄图,只要你的黄图不让其它用户觉得恶心,不涉及儿童色情,他们就不会干涉你发成人内容。 甚至于他们在自己用户条款里写着,“当然,欢迎你发布成人内容”。 很多人都觉得即使这样允许发黄图,网站流量还是会以正常的图片为主,但事实上并不是,有统计显示,tumblr上敏感色情内容的比例,超过三成,已经成为该大型图片社交社区内容最重要的比例之一。 这时候你才会发现,对色情内容的需求原来这么旺盛,就像《Q大道》里唱的那样,很多人“上网就是为了看毛片…

Read More Read More

Kubernetes集群搭建:基于Kubeadm

Kubernetes集群搭建:基于Kubeadm

閱讀本文約花費: 16 (分鐘)一,环境准备 * K8S版本为15.1 * Docker版本最高支持18.06.1 二,Docker环境构建及替换 1,清除原Docker环境,原版本为最新版 yum remove docker \docker-client \docker-client-latest \docker-common \docker-latest \docker-latest-logrotate \docker-logrotate \docker-selinux \docker-engine-selinux \docker-engine rm -rf /etc/systemd/system/docker.service.d rm -rf /var/lib/docker rm -rf /var/run/docker 2,如果清除后依旧包冲突错误 file /usr/share/man/man1/docker-manifest-annotate.1.gz from install of docker-ce-18.06.1.ce-3.el7.x86_64 conflicts with file from package docker-ce-cli-1:18.09.6-3.el7.x86_64 通过yum命令手动移除冲突包 yum erase docker-common-2:1…

Read More Read More

使用Istio治理微服务入门

使用Istio治理微服务入门

閱讀本文約花費: 20 (分鐘)近两年微服务架构流行,主流互联网厂商内部都已经微服务化,初创企业虽然技术积淀不行,但也通过各种开源工具拥抱微服务。再加上容器技术赋能,Kubernetes又添了一把火,微服务架构已然成为当前软件架构设计的首选。 但微服务化易弄,服务治理难搞! 一、微服务的“痛点” 微服务化没有统一标准,多数是进行业务领域垂直切分,业务按一定的粒度划分职责,并形成清晰、职责单一的服务接口,这样每一块规划为一个微服务。微服务之间的通信方案相对成熟,开源领域选择较多的有RPC或RESTful API方案,比如:gRPC、Apache Thrift等。这些方案多偏重于数据如何打包、传输与解包,对服务治理的内容涉及甚少。 微服务治理是头疼的事,也是微服务架构中的痛点。治理这个词有多元含义,很难下达一个精确定义,这里可以像小学二年级学生那样列出治理的诸多近义词:管理、控制、规则、掌控、监督、支配、规定、统治等。对于微服务而言,治理体现在以下诸多方面: 服务注册与发现 身份验证与授权 服务的伸缩控制 反向代理与负载均衡 路由控制 流量切换 日志管理 性能度量、监控与调优 分布式跟踪 过载保护 服务降级 服务部署与版本升级策略支持 错误处理 …… 从微服务治理角度来说,微服务其实是一个“大系统”,要想将这个大系统全部落地,绝非易事,尤其是之前尚没有一种特别优雅的技术方案。多数方案(…

Read More Read More

商旅网站用户画像的解决方案

商旅网站用户画像的解决方案

閱讀本文約花費: 11 (分鐘)(一)用户画像的目的与意义、构建步骤 用户画像(persona)的概念最早由交互设计之父Alan Cooper 提出:是指真实用户的虚拟代表,是建立在一系列属性数据之上的目标用户模型。随着互联网的发展,现在我们说的用户画像是根据用户人口学特征、网络浏览内容、网络社交活动和消费行为等信息而抽象出的一个标签化的用户模型。通过各个维度对用户或者产品特征属性的刻画,并对这些特征分析统计挖掘潜在价值信息!完美地抽象出一个用户的信息全貌,可以看作企业应用大数据的根基。构建用户画像的核心工作,主要是利用存储在服务器上的海量日志和数据库里的大量数据进行分析和挖掘,给用户贴“标签”,而“标签”是能表示用户某一维度特征的标识。 为了能解决业务问题,用数据来帮助企业了解用户和定位产品,更好地解决业务问题,首先必须明确业务目标。用户画像是帮助企业明确目标客群,当企业了解了自己的用户都长什么样子以后,接下来的任务就是如何将有类似画像特征人群的潜在用户变成自己的用户,也就是在营销上获新客的过程。 所以,从大的框架来看,用户画像承载了两个业务目标: 一是如何准确的了解现有用户; 二是如何在茫茫人海中通过广告营销获取类似画像特征的新用户。 那么用户画像具体有什么作用,能帮助我们达到哪些目标呢?大体上可以总结为以下几个方面: 1. 精准营销:精准直邮、短信、App消息推送、个性化广告…

Read More Read More

图文:千万级高性能长连接网关是如何搭建的?

图文:千万级高性能长连接网关是如何搭建的?

閱讀本文約花費: 17 (分鐘)实时的响应总是让人兴奋的,就如你在微信里看到对方正在输入,如你在王者峡谷里一呼百应,如你们在直播弹幕里不约而同的 666,它们的背后都离不开长连接技术的加持。 每个互联网公司里几乎都有一套长连接系统 ,它们被应用在消息提醒、即时通讯、推送、直播弹幕、游戏、共享定位、股票行情等等场景。而当公司发展到一定规模,业务场景变得更复杂后,更有可能是多个业务都需要同时使用长连接系统。 业务间分开设计长连接会导致研发和维护成本陡增、浪费基础设施、增加客户端耗电、无法复用已有经验等等问题。共享长连接系统又需要协调好不同系统间的认证、鉴权、数据隔离、协议拓展、消息送达保证 等等需求,迭代过程中协议需要向前兼容,同时因为不同业务的长连接汇聚到一个系统导致容量管理的难度也会增大。 经过了一年多的开发和演进,经过我们服务面向内和外的数个 App、接入十几个需求和形态各异的长连接业务、数百万设备同时在线、突发大规模消息发送等等场景的锤炼,我们提炼出一个长连接系统网关的通用解决方案,解决了多业务共用长连接时遇到的种种问题。 知乎长连接网关致力于业务数据解耦、消息高效分发、解决容量问题,同时提供一定程度的消息可靠性保证。 我们怎么设计通讯协议? 业务解耦 支撑多业务的长连接网关实际上是同时对接多客户端和多业务后端的,是多对多的关系,他们之间只使用一条长连接通讯。 这种多对多的系统…

Read More Read More

kubernetes实践:Istio之策略与遥测

kubernetes实践:Istio之策略与遥测

閱讀本文約花費: 9 (分鐘)一:Istio简介 1.Istio定义 一个用来连接,管理和保护服务的开发平台。Istio提供一种简单的方式建立已部署服务网络,具备负载均衡,服务间认证和监控等功能。 而不需要改变任何服务代码。想要为服务增加对Istio的支持,只需要在环境中部署一个sidecar,使用Istio控制面板功能配置和管理代理,拦截微服务之间的所有网络通信。 2.为什么需要Istio 随着微服务出现,微服务的连接,管理和监控成为难题。Kubernetes可以处理多个容器的工作负载,但当涉及更复杂的需求时,需要像Istio这样的服务网格。 3.Istio的主要功能 a.流量管理(Pilot): 控制服务之间的流量和API调用的流向,使得调用更灵活可靠,并使网络在恶劣情况下更加健壮。 b.可观察性: 通过集成zipkin等服务,快速了解服务之间的依赖关系,以及它们之间流量的本质和流向,从而提供快速识别问题的能力。 c.策略执行(mixer): 将组织策略应用于服务之间的互动,确保访问策略得以执行,资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。 d.服务身份和安全(Istio-auth): 为网格中的服务提供可验证身份,并提供保护服务流量的能力,使其可以在不同可信度的网络上流转。 4.Envoy架构 a.svcA服务作为客户端点用服务端svcB,svc…

Read More Read More

YAML 语言教程

YAML 语言教程

閱讀本文約花費: 6 (分鐘)编程免不了要写配置文件,怎么写配置也是一门学问。 YAML 是专门用来写配置文件的语言,非常简洁和强大,远比 JSON 格式方便。 本文介绍 YAML 的语法,以 JS-YAML 的实现为例。你可以去在线 Demo 验证下面的例子。 一、简介 YAML 语言(发音 /ˈjæməl/ )的设计目标,就是方便人类读写。它实质上是一种通用的数据串行化格式。 它的基本语法规则如下。 大小写敏感 使用缩进表示层级关系 缩进时不允许使用Tab键,只允许使用空格。 缩进的空格数目不重要,只要相同层级的元素左侧对齐即可 # 表示注释,从这个字符一直到行尾,都会被解析器忽略。 YAML 支持的数据结构有三种。 对象:键值对的集合,又称为映射(mapping)/ 哈希(hashes) / 字典(dictionary) 数组:一组按次序排列的值,又称为序列(sequence) / 列表(list) 纯量(scalars):单个的、不可再分的值 以下分别介绍这三种数据结构。 二、对象 对象的一组键值对,使用冒号结构表示。 转为 JavaScript 如下。 Yaml 也允许另一种写法,将所有键值对写成一个行内对象。 转为 JavaScript 如下。 三、数组 一组连词线开头的行,构成一个数组。 转为 JavaScript 如下。 数据…

Read More Read More

Serverless 与容器决战在即?有了弹性伸缩就不一样了

Serverless 与容器决战在即?有了弹性伸缩就不一样了

閱讀本文約花費: 16 (分鐘)导读:Serverless 和 Autoscaling 是近些年来广大开发者非常关心的内容。有人说 Serverless 是容器 2.0,终有一天容器会和 Serverless 进行一场决战,分出胜负。实际上,容器和 Serverless 是可以共存并且互补的,特别是在 Autoscaling 相关的场景下,Serverless 可以与容器完美兼容,弥补容器场景在使用简单、速度、成本的缺欠。 当我们在谈论”弹性伸缩”的时候 当我们在谈论”弹性伸缩”的时候,我们在谈论什么?”弹性伸缩”对于团队中不同的角色有不同的意义,而这正是弹性伸缩的魅力所在。 从一张资源曲线图讲起 这张图是阐述弹性伸缩问题时经常引用的一张图,表示的是集群的实际资源容量和应用所需容量之间的关系。 其中红色的曲线表示的是应用实际所需的容量,因为应用的资源申请量相比节点而言会小很多,因此曲线相对比较平滑; 而绿色的折线表示的是集群的实际资源容量,折线的拐点表明此时进行了手动的容量调整,例如增加节点或者移除节点,因为单个节点的资源容量固定且相对较大,因此以折线为主。 首先,我们先看左侧第一块黄色栅格的区域,这个区域表示集群的容量无法满足业务的容量所需,在实际的场景中,通常会伴随出现由于资源不足而无法调度的 Pod 等现…

Read More Read More

微服务架构下的分布式限流方案全解析

微服务架构下的分布式限流方案全解析

閱讀本文約花費: 9 (分鐘)1.微服务限流 随着微服务的流行,服务和服务之间的稳定性变得越来越重要。缓存、降级和限流是保护微服务系统运行稳定性的三大利器。 缓存的目的是提升系统访问速度和增大系统能处理的容量,而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉,待高峰或者问题解决后再打开,而有些场景并不能用缓存和降级来解决,比如稀缺资源、数据库的写操作、频繁的复杂查询,因此需有一种手段来限制这些场景的请求量,即限流。 比如当我们设计了一个函数,准备上线,这时候这个函数会消耗一些资源,处理上限是1秒服务3000个QPS,但如果实际情况遇到高于3000的QPS该如何解决呢? 所以限流的目的应当是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统,一旦达到限制速率就可以拒绝服务、等待、降级。 学习如何去实现一个分布式限流框架,首先,我们需要去了解最基本的两种限流算法。 2.限流算法 2.1漏桶算法 漏桶算法思路很简单,水(也就是请求)先进入到漏桶里,漏桶以一定的速度出水,当水流入速度过大会直接溢出,然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率。示意图(来源网络)如下: 2.2令牌桶算法 令牌桶算法和漏桶算法效果一样但方向相反的算法,更加容易理解。随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入令牌(…

Read More Read More

Java 应用性能调优实践

Java 应用性能调优实践

閱讀本文約花費: 24 (分鐘)Java 应用性能优化是一个老生常谈的话题,典型的性能问题如页面响应慢、接口超时,服务器负载高、并发数低,数据库频繁死锁等。尤其是在”糙快猛”的互联网开发模式大行其道的今天,随着系统访问量的日益增加和代码的臃肿,各种性能问题开始纷至沓来。Java 应用性能的瓶颈点非常多,比如磁盘、内存、网络 I/O 等系统因素,Java 应用代码,JVM GC,数据库,缓存等。笔者根据个人经验,将 Java 性能优化分为 4 个层级:应用层、数据库层、框架层、JVM 层,如图 1 所示。 图 1.Java 性能优化分层模型 每层优化难度逐级增加,涉及的知识和解决的问题也会不同。比如应用层需要理解代码逻辑,通过 Java 线程栈定位有问题代码行等;数据库层面需要分析 SQL、定位死锁等;框架层需要懂源代码,理解框架机制;JVM 层需要对 GC 的类型和工作机制有深入了解,对各种 JVM 参数作用了然于胸。 围绕 Java 性能优化,有两种最基本的分析方法:现场分析法和事后分析法。现场分析法通过保留现场,再采用诊断工具分析定位。现场分析对线上影响较大,部分场景(特别是涉及到用户关键的在线业务时)不太合适。事后分析法需要尽可能多收集现场数据,然后立即恢复服务,同时针对收集的现场数据进行事后分析和复现。下面我们从性能诊断工具出发,分享搜狗商业平台在其中的一些案例与实践。 性…

Read More Read More

SpringCloud之Ribbon负载均衡的入门操作

SpringCloud之Ribbon负载均衡的入门操作

閱讀本文約花費: 6 (分鐘)使用Ribbon进行负载均衡 在使用Ribbon之前,我们先想一个之前的问题,之前我们将服务提供者注册进了eureka注册中心,但是在消费者端,我们还是使用的restTemplate调用的时候,其中写的还是http://localhost:8001这样的调用方式,是不是有一些不妥呢?是不是应用像dubbo那样,使用服务名进行调用呢?不然,我们使用注册中心有什么用呢? 好的呢,我们先保留这个思考 。来进入Ribbon的学习 什么是Ribbon? Ribbon [?r?b?n] ,是SpringCloud Netflix中的一个关于客户端的负载均衡插件。 主要解释如下: 这个客户端主要是指服务消费者,也就是说,这个插件是用在消费者端的,它自己会根据一些算法对相同服务的提供者(也就是这几个服务提供者的application.name要相同)进行甄别,自己决定我要访问哪一个服务者。 而Nginx是整个服务器的负载均衡,当浏览器等设备的访问请求进来后,它会根据自身的配置,进行服务的路径选择。 Ribbon的集成(客户端,即消费者) 上边说了,是在消费端进行的负载均衡,所以要修改cousumer端,但为了方便学习,我就新创建了一个项目,demo3-ribbon-consumer,代码和之前的没什么太大的变化。而且,要有多个相同名称的服务提供者才能进行负载均衡,才能…

Read More Read More

SpringCloud-Ribbon[入门案例]

SpringCloud-Ribbon[入门案例]

閱讀本文約花費: 4 (分鐘)一、 Ribbon 在微服务中的作用 1 什么是 Ribbon Ribbon 是一个基于 Http 和 TCP 的客服端负载均衡工具,它是基于 Netflix Ribbon 实现的。 它不像 spring cloud 服务注册中心、配置中心、API 网关那样独立部署,但是它几乎存在于每个 spring cloud 微服务中。包括 feign 提供的声明式服务调用也是基于该 Ribbon实现的。 ribbon 默认提供很多种负载均衡算法,例如 轮询、随机 等等。甚至包含自定义的负载均衡算法。 2 Ribbon 解决了什么问题 他解决并提供了微服务的负载均衡的问题。 二、 集中式与进程内负载均衡的区别 1 负载均衡解决方案的分类 目前业界主流的负载均衡方案可分成两类: 第一类:集中式负载均衡, 即在 consumer 和 provider 之间使用独立的负载均衡设施(可以是硬件,如 F5, 也可以是软件,如 nginx), 由该设施负责把 访问请求 通过某种策略转发至 provider; 第二类:进程内负载均衡,将负载均衡逻辑集成到 consumer,consumer 从服务注册中心获知有哪些地址可用,然后自己再从这些地址中选择出一个合适的 provider。Ribbon 就属于后者,它只是一个类库,集成于 consumer 进程,consumer 通过它…

Read More Read More

Service Mesh Is Still Hard

Service Mesh Is Still Hard

閱讀本文約花費: 5 (分鐘)KubeCon + CloudNativeCon NA Virtual sponsor guest post from Lin Sun, Senior Technical Staff Member at IBM At ServiceMeshCon EU this August, William Morgan from Linkerd and I gave a joint talk entitled service mesh is still hard.  William detailed the improvements to Linkerd, while I covered the improvements to Istio.  It’s clear both projects are working hard to make it easier for users to adopt service mesh. Service mesh is more mature than it was one or two years ago, however, it’s still hard for users.  There are two types of …

Read More Read More

6种微服务RPC框架,你知道几个?

6种微服务RPC框架,你知道几个?

閱讀本文約花費: 7 (分鐘)跟语言平台绑定的开源 RPC 框架主要有下面几种。 Dubbo:国内最早开源的 RPC 框架,由阿里巴巴公司开发并于 2011 年末对外开源,仅支持 Java 语言。 Motan:微博内部使用的 RPC 框架,于 2016 年对外开源,仅支持 Java 语言。 Tars:腾讯内部使用的 RPC 框架,于 2017 年对外开源,仅支持 C++ 语言。 Spring Cloud:国外 Pivotal 公司 2014 年对外开源的 RPC 框架,仅支持 Java 语言 而跨语言平台的开源 RPC 框架主要有以下几种。 gRPC:Google 于 2015 年对外开源的跨语言 RPC 框架,支持多种语言。 Thrift:最初是由 Facebook 开发的内部系统跨语言的 RPC 框架,2007 年贡献给了 Apache 基金,成为 Apache 开源项目之一,支持多种语言。 如果你的业务场景仅仅局限于一种语言的话,可以选择跟语言绑定的 RPC 框架中的一种; 如果涉及多个语言平台之间的相互调用,就应该选择跨语言平台的 RPC 框架。 RPC 框架,它们具体有何区别? 1. Dubbo 先来聊聊 Dubbo,Dubbo 可以说是国内开源最早的 RPC 框架了,目前只支持 Java 语言,它的架构可以用下面这张图展示。 从图中你能看到,Dubbo 的架构主要包含四…

Read More Read More

项目架构之传统三层架构和领域模型三层架构

项目架构之传统三层架构和领域模型三层架构

閱讀本文約花費: 18 (分鐘)一、工程结构 本系列文章所示范的项目基于传统三层架构进行分层,基于工作职责和Maven结构进行模块划分。本文将对传统三层架构和对应的领域模型架构、以及每个模块的职责进行简单的说明。下图即示范项目的模块结构: 二、架构之传统三层架构 传统三层架构是一种软件架构,是一种典型的、基于贫血模型的、面向过程的JavaWeb分层方式。该架构分为以下三个层次: 数据访问层(DAL – Data Access Layer)即对包括数据库在内的数据源进行操作的部分。 业务逻辑层(BLL – Business Logic Layer)即对业务数据进行逻辑处理的部分。 表现层(UI – User Interface)即与用户交互的部分。 分层的目的是为了解耦和明确责任。开发人员可以只关心自己所负责的那一层,因为他只需要知道上一层提供了哪些接口,从而利用这些接口进行编程。而上一层的开发人员在不改变接口的情况下,可以任意地替换具体的实现,从而实现松耦合。 相比更传统的架构,三层架构有着明显的优势,但也有不可忽视的缺点。初期的JavaWeb在JSP内同时进行数据库读写、业务逻辑处理和页面渲染,简单而暴力。而今的架构,在JSP之上增加了一个处理业务逻辑的中间层和一个封装了数据库操作的数据访问层,毫无疑问造成了代码量的大幅度上升和效率的下降。 本…

Read More Read More

WordPress post和page的区别

WordPress post和page的区别

閱讀本文約花費: 1 (分鐘)  wordpress博客主要有两部分构成posts和pages,但是对于wordpress初学者来说,经常把这两个概念混淆。在post和page之间有很多不同点,知道并理解这些不同点,能够让我们更好的使用wordpress中的pages和posts。 post的特点: 1、post通常按发布时间倒序排列 2、post经常被更新,需要显示发布时间 3、可以通过标签和分类来组织post 4、post会出现在Rss订阅中 page的特点: 1、博客中的page页面独立于post显示,通常很少发生变动 2、通常使用page来和读者分享信息,但是很少去更新它 3、page页面没有发布时间,我们不需要显示page发布的时间 4、根据主题的不同,page可以显示在任何地方 5、page通常按字母排序,但是我们可以改变排序的方式 6、page没有标签和分类 7、page页面不会出现在RSS源中,读者需要访问博客才能看到page页面的更新情况 8、不要在page页面中嵌入Post 9、通过page页面之间的父子关系,可以建立复杂的网站结构 所以像留言板、关于、友链这样的页面喜欢用page,而一般文章则是用post Tags: WordPress, 博客

     
Scroll Up