Browsed by
标签:Nginx

技术名站

技术名站

閱讀本文約花費: 6 (分鐘)收藏一些有关网站开发、建设、SEO、技术学习与交流的名站,也可以说是我认为对我和对广大网站爱好者们有学习参考价值的网站、个人博客等。 IT新闻类 51CTO.COM 中国领先的IT技术网站 雷锋网 新技术 E4A 易安卓,以下简称E4A,是一个基于谷歌Simple语言的编程工具,旨在实现通过类似易语言的Basic语法轻松编写Android应用程序。只要你有易语言的基础,就可以很轻松上手。E4A拥有和易语言一样的可视化开发环境,以及强大的智能语法提示功能。纯中文编写代码,比英文更具亲和力,您也无需为记不住英文关键词而烦恼。E4A已经内置了Android1.5开发包SDK,您只需额外下载安装Java1.6开发包JDK即可。目前E4A还处于初级阶段。 RabbitMQ 是实现了高级消息队列协议(AMQP)的开源消息代理软件(亦称面向消息的中间件)。RabbitMQ服务器是用Erlang语言编写的,而集群和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库 织梦 织梦标签生成器//tools.dedecms.com/dedetag_maker.html 织梦帮助中心//help.dedecms.com/ 织梦二次开发帮助手册(这个页面我打开是有乱码,在浏览器中字符编码再点一下“简体中文”就好了)//tool…

Read More Read More

如何Docker化任意一个应用

如何Docker化任意一个应用

閱讀本文約花費: 10 (分鐘)网上有很多关于如何将应用 Docker 化的教程,为什么我还要再写一个呢? 我见过的大部分教程都是限定在某种特定技术(例如 Java 或者 Python),可能无法满足读者的需求。同时,这些教程也没有说清楚关于 Dev 和 Ops 团队之间建立明确约定所涉及到的所有相关方面(这正是容器化的精髓所在)。 我根据最近的经验总结了以下一些步骤。它是一份细节清单,包含了其他指南中忽略的内容。 声明:这不是一份新手指南。我建议读者先掌握一些如何设置和使用 docker 的基础知识,并且创建和运行一些容器之后,再来阅读。 让我们开始吧。 一、选择基础镜像 每种对应技术几乎都有自己的基础镜像,例如: https://hub.docker.com/_/java/ https://hub.docker.com/_/python/ https://hub.docker.com/_/nginx/ 如果不能直接使用这些镜像,我们就需要从基础操作系统镜像开始安装所有的依赖。 外面有很多教程使用的都是 Ubuntu(例如 ubuntu:16.04)作为基础镜像,这不能算有问题,但是我建议优先考虑 Alpine 镜像: https://hub.docker.com/_/alpine/ 它是一个非常小的基础镜像(大约只有 5MB)。 注意:在基于 Alpine 的镜像中无法使用“a…

Read More Read More

如何在Kubernetes中管理有状态应用

如何在Kubernetes中管理有状态应用

閱讀本文約花費: 7 (分鐘)在Kubernetes中,StatefulSet被用来管理有状态应用的API对象。StatefulSets在Kubernetes 1.9版本才稳定。StatefulSet管理Pod部署和扩容,并为这些Pod提供顺序和唯一性的保证。与Deployment相似的地方是,StatefulSet基于spec规格管理Pod;与Deployment不同的地方是,StatefulSet需要维护每一个Pod的唯一身份标识。这些Pod基于同样的spec创建,但互相之间不能替换,每一个Pod都保留自己的持久化标识。 ———- 1、使用StatefulSet的场景 对于下面的应用场景,StatefulSets是有价值的: 稳定、唯一的网络标识 稳定、持久的存储 按照顺序、优雅的部署和扩容 按照顺序、优雅的删除和终止 按照顺序、自动滚动更新 上述的稳定是持久的同义词,如果应用不需要稳定的标识或者顺序的部署、删除、扩容,则应该使用无状态的副本集。Deployment或者ReplicaSet的控制器更加适合无状态业务场景。 2、StatefulSet的限制 在Kubernetes 1.9版本之前是beta版本,在Kubernetes 1.5版本之前是不提供的。 Pod存储由PersistentVolume(storage类或者管理员预先创建)提…

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

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

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

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

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 实践探索

蚂蚁金服 Service Mesh 实践探索

閱讀本文約花費: 50 (分鐘)摘要 在勇敢的选择了Service Mesh作为未来技术方向之后,蚂蚁金服率先开始了Service Mesh大规模落地探索。在此过程中,我们遇到很多问题,面临各种挑战,也有了一些思路和方法。今天我们将这些实践分享出来,并结合我们开源的SOFAMesh项目,和大家一起探讨:如何更好的将Service Mesh这样的新兴技术落地于实际生产环境。 大家好,我是来自蚂蚁金服中间件团队的敖小剑,目前是蚂蚁金服 Service Mesh 项目的PD。我同时也是 Servicemesher中国技术社区 的创始人,是 Service Mesh 技术在国内最早的布道师。我今天给大家带来的主题是”长路漫漫踏歌而行:蚂蚁金服Service Mesh实践探索”。 今天我们的内容不是继续做 Service Mesh 的布道,今年要好好讲一讲实践。所以今天我不会像去年那样给大家详细解释 Service Mesh 是什么,能做什么,有什么优势。而是结合过去一年中蚂蚁金服的实践经验,结合蚂蚁金服的 SOFAMesh 产品,帮助大家更深刻的理解 Service Mesh 技术。 在开始今天的内容分享之前,我们先来热个身,温习一下去年的内容。去年我是来布道的,而布道的核心内容就是告诉大家:Service Mesh 是什么? 为了帮忙大家回答,我给出一个提示图片,了解 Service M…

Read More Read More

高并发架构的设计

高并发架构的设计

閱讀本文約花費: 10 (分鐘)1、什么是高并发 1)高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常 是指,通过设计保证系统能够同时并行处理很多请求。 2)高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查 询率 QPS(Query Per Second),并发用户数等。 3)响应时间:系统对请求做出响应的时间。例如系统处理一个 HTTP 请求需要 200ms,这个 200ms 就是系统的响应时间。 4)吞吐量:单位时间内处理的请求数量。 5)QPS:每秒响应请求数。在互联网领域,这个指标和吞吐量区分的没有这么明显。 6)并发用户数:同时承载正常使用系统功能的用户数量。例如一个即时通讯系统,同时在线量 一定程度上代表了系统的并发用户数。 2、如何提升系统的并发能力 互联网分布式架构设计,提高系统并发能力的方式,方法论上主要有两种:垂直扩展 (Scale Up)与水平扩展(Scale Out)。 垂直扩展:提升单机处理能力。垂直扩展的方式又有两种: 1)增强单机硬件性能,例如:增加 CPU 核数如 32 核,升级更好的网卡如万兆,升级更 好的硬盘如 SSD,扩充硬盘容量如 2T,扩充系统内存如 128G; 2)提升单机架构性能,例如:使用 Cache 来减少 IO 次数,使用异步来…

Read More Read More

一个可供参考的Java高并发异步应用案例

一个可供参考的Java高并发异步应用案例

閱讀本文約花費: 11 (分鐘) 泰康在线微信公众号系泰康在线财产保险股份有限公司旗下平台,希望可以通过持续不断的创新,提升客户对于保险的认知及体验,通过对大数据技术的应用,精准的为客户设计产品以及提供服务。泰康在线微信公众号,现有1000多万粉丝。在日常的运营中,借助于红包奖励、卡券分享、消息通知、微信分享等手段,通过好的内容,好的活动、好的产品以及相应的精准营销来增强用户的粘性和活跃度。在日常运营中,公众号会通过给用户下发营销或者科普类的消息来通知客户。 根据经验,微信消息下发后10分钟后流量会逐步上升,30分钟左右到达峰值,1个小时后会显著下降。在这个时间段内,系统的压力会很大。在系统设计和改进中,系统的很多场景使用异步进行实现,一方面能缩短主流程的时间处理,另一方面能够通过异步队列进行一定程度的削峰。今天重点介绍单个JVM内的异步优化实践,不涉及分布式时的异步优化实践。在异步执行时,可以调用远程的服务集群来实现一定的任务分解。部署示意图整个系统都部署在公有云上,虚拟机上有部署1个Nginx,4个Tomcat,Nginx使用随机的方式负载均衡到Tomcat上面。虚机之间通过LB将客户请求转发到Nginx上面负载均衡,Nginx再将请求分配到tomcat应用服务器上。由多台应用服务器,对外服务提供Rest服务,在每个Tomcat内部使用异步队列。同时由一台控制服务器,进行异步任…

Read More Read More

从PHP到Node,聊一聊淘宝首页背后的技术

从PHP到Node,聊一聊淘宝首页背后的技术

閱讀本文約花費: 22 (分鐘)“作者从2014年双十二结束时开始接手淘宝首页,经历了淘宝首页的两次改版和一次从PHP到Node的迁移,不久前完成了工作的交接。本文介绍了淘宝首页的变迁过程、性能优化、稳定性保障和敏捷措施,分享了作者在此过程中的感受。 相关背景介绍 淘宝首页是淘宝的门面,承载着几乎淘系所有业务的入口,流量很大,量级单位为亿。近几年无线端崛起,业务重点开始向无线终端偏移(目前不能叫偏移,基本以无线为主了),所以淘宝 PC 端首页的流量也有削减,不过即便如此,它的日均 PV 依然相当高。 淘宝首页一向是内部平台和技术的试验田,它一直在变化着。最新的框架和系统都会找淘宝首页试点,可以试想下,如果某一项需要推动的升级或者优化措施在淘宝首页已经上线,并且拿到了良好的数据和稳定性,其他业务还有什么理由不去尝试和更迭呢?同时,去年一年身在淘宝前端的技术架构组,自然而然也会主动去 push 一些实验性的内容到业务上。 淘系的站点页面包括首页、其他频道页和活动页等,这些页面并不都由淘宝前端一行一行的代码码出来,业务如此之多,这种玩法即便人数 double 也忙不过来。事实上,大多数页面都是依托内部的搭建平台一一运营或者前端通过模块搭建的方式一一构建的,而前端 focus 的重点在于搭建平台的建设自身以及模块的通用性和复用率的保障,当然,还有一些工程化的东西。 使用搭建平台搭建的页面,…

Read More Read More

Docker不香吗,为啥还要K8s?

Docker不香吗,为啥还要K8s?

閱讀本文約花費: 16 (分鐘)上一篇文章我们着重讲解了 Docker,其实遗留了一个大问题。Docker 虽好用,但面对强大的集群,成千上万的容器,突然感觉不香了。 这时候就需要我们的主角 Kubernetes 上场了,先来了解一下 K8s 的基本概念,后面再介绍实践,由浅入深步步为营。 关于 K8s 的基本概念我们将会围绕如下七点展开: Docker 的管理痛点 什么是 K8s? 云架构 & 云原生 K8s 架构原理 K8s 核心组件 K8s 的服务注册与发现 关键问题 Docker 的管理痛点 如果想要将 Docker 应用于庞大的业务实现,是存在困难的编排、管理和调度问题。 于是,我们迫切需要一套管理系统,对 Docker 及容器进行更高级更灵活的管理。 Kubernetes 应运而生!Kubernetes,名词源于希腊语,意为「舵手」或「飞行员」。 image Google 在 2014 年开源了 Kubernetes 项目,建立在 Google 在大规模运行生产工作负载方面拥有十几年的经验的基础上,结合了社区中最好的想法和实践。 K8s 是 Kubernetes 的缩写,用 8 替代了 「ubernete」,下文我们将使用简称。 什么是 K8s ? image K8s 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。 …

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

架构设计-谈谈架构

架构设计-谈谈架构

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

Read More Read More

聊聊ServiceMesh 数据面板 Envoy

聊聊ServiceMesh 数据面板 Envoy

閱讀本文約花費: 27 (分鐘)Envoy 简介 在 Service Mesh 模式中,每个服务都配备了一个代理“sidecar”,用于服务之间的通信。这些代理通常与应用程序代码一起部署,并且它不会被应用程序所感知。Service Mesh 将这些代理组织起来形成了一个轻量级网络代理矩阵,也就是服务网格。这些代理不再是孤立的组件,它们本身是一个有价值的网络。其部署模式如图所示: 绿色部分代表应用程序 蓝色部分则是sidecar 服务网格是用于处理服务到服务通信的“专用基础设施层”。它通过这些代理来管理复杂的服务拓扑,可靠地传递服务之间的请求。 从某种程度上说,这些代理接管了应用程序的网络通信层。 Envoy是 Service Mesh 中一个非常优秀的 sidecar 的开源实现。我们就来看看 Envoy 都是做些什么工作。 Envoy 用到的几个术语 Host: 通常我们将 Host 看做是一个具备网络通信功能的实体(可以是一台物理机,也可以是一台移动设备等等) 。在 Envoy 中,host 是一个逻辑网络中的应用. 可能运行在由有多个主机组成的底层硬件,只要它们各自独立寻址。 Downstream: 请求发起者(服务请求方)。 Upstream: 请求接收者(服务提供方)。 Listener: 服务(程序)监听者。就是真正干活的。 envoy 会暴露一个或者多个listene…

Read More Read More

Scroll Up