最新 | 最热门 | 最高评价

+0  Blog安全问题小记

Tag: Security | DDos | PHP | WordPress | XML-RPC Attack
四火 发于 2017年11月21日 03:50 | 点击: 718 | 展开摘要
最近Blog遭遇了几个安全问题,折腾了几个钟头,在此记录一下。

最大的问题是blog访问时不时地出现“502 bad gateway”,即便不出现,latency也能达到接近三十秒。

于是登上vps去看原因,top命令发现CPU都用完了。靠,十个php-fpm居然都在满功率工作。研究了一下,通常php-fpm在没有请求的时候是不应该占用那么多CPU资源的,而且mysql也高,似乎有人在访问网站,但是去access log里面却没找到东西:

top - 02:08:12

查看全文: http://www.udpwork.com/item/16506.html

+0  gRPC的那些事 - interceptor

Tag: gRPC | Go
鸟窝 发于 2017年04月17日 13:41 | 点击: 695 | 展开摘要
gRPC-Go 增加了拦截器(interceptor)的功能, 就像Java Servlet中的 filter一样,可以对RPC的请求和响应进行拦截处理,而且既可以在客户端进行拦截,也可以对服务器端进行拦截。

利用拦截器,可以对gRPC进行扩展,利用社区的力量将gRPC发展壮大,也可以让开发者更灵活地处理gRPC流程中的业务逻辑。下面列出了利用拦截器实现的一些功能框架:

Go gRPC Middleware:提供了拦截器的interceptor链式的功能,可以将多个拦截器

查看全文: http://www.udpwork.com/item/16216.html

+0  [转]gRPC服务发现&负载均衡

Tag: gRPC | Go
鸟窝 发于 2017年03月26日 00:07 | 点击: 1197 | 展开摘要
原文出处: gRPC服务发现&负载均衡, 作者: softfn。

构建高可用、高性能的通信服务,通常采用服务注册与发现、负载均衡和容错处理等机制实现。根据负载均衡实现所在的位置不同,通常可分为以下三种解决方案:

1、集中式LB(Proxy Model)

在服务消费者和服务提供者之间有一个独立的LB,通常是专门的硬件设备如 F5,或者基于软件如 LVS,HAproxy等实现。LB上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向LB

查看全文: http://www.udpwork.com/item/16189.html

+0  RPCX: 一个用Go实现的类似Dubbo的分布式RPC框架

Tag: RPC | Go
鸟窝 发于 2016年06月15日 10:43 | 点击: 7478 | 展开摘要
rpcx是一个类似阿里巴巴 Dubbo 和微博 Motan 的分布式的RPC服务框架,基于Golang net/rpc实现。

谈起分布式的RPC框架,比较出名的是阿里巴巴的dubbo,包括由当当网维护的dubbox。
不知道dubbo在阿里的内部竞争中败给了HSF,还是阿里有意将其闭源了,官方的代码使用的spring还停留在2.5.6.SEC03的版本,dubbox的spring也只升级到3.2.9.RELEASE。
不管怎样,dubbo还是在电商企业得到广泛的应用,京东

查看全文: http://www.udpwork.com/item/15521.html

+0  在线服务的黑天鹅

Tag: service | fault-tolerance | rpc
Tim 发于 2014年12月22日 01:20 | 点击: 970 | 展开摘要
软件随想录(More Joel on Software)有这样一段话

提高服务稳定性的最大困难,就是”黑天鹅难题”(problem of black swans)。这个名词是由Nassim Taleb提出来的(www.edge.org/3rd_culture/taleb04/taleb_indexx.html),他这样定义:”黑天鹅代表外来因素,是一个超出正常预料的事件。”几乎所有的互联网服务中断,都来自于意料之外的突发事件,

查看全文: http://www.udpwork.com/item/13663.html

+0  应用层的容错与分层设计

Tag: service | finagle | rpc | twitter
Tim 发于 2014年11月07日 12:24 | 点击: 1051 | 展开摘要
针对在项目中碰到的一些容错设计问题,团队最近进行了一次技术沙龙,讨论了以下话题。

为什么需要应用层的容错设计?

一个完整的系统在内部是由很多小服务构成,服务之间以及服务与资源之间会存在远程调用。

每个系统的可用性不可能达到100%

各种网络及硬件问题,如网络拥堵、网络中断、硬件故障……

远程服务平均响应速度变慢

服务器平均响应速度如果慢下来,慢慢消耗掉系统所有资源,进而导致整个系统不可用。因此在分布式系统中,除了远程服务本身需要有容错设计之外,在应用层的远程调用

查看全文: http://www.udpwork.com/item/13486.html

+0  NFS-RPC框架优化过程(从37k到168k)

Tag: nio tuning | rpc benchmark | Grizzly | RPC | Java | rpc tuning | java | netty | mina
bluedavy 发于 2011年09月13日 10:33 | 点击: 4436 | 展开摘要
NFS-RPC框架从编写之初,到现在为止(应该还会有些提升,不过估计不大),每秒支撑的请求数上升了好几倍,测试结果的演变为:

37k –> 56k –> 65k –> 88k –> 93k –> 143k –> 148k –> 153k –> 160k –> 163k –> 168k

以上测试结果为在100并发、100 request byte、100

查看全文: http://www.udpwork.com/item/5787.html

+0  Let’s beat the rpc benchmark record,current is 168k!

Tag: Netty Benchmark | Grizzly | Mina Benchmark | Java Network Framework | nfs-rpc | RPC | Scala | NIO | Java | AIO
bluedavy 发于 2011年08月27日 14:36 | 点击: 2319 | 展开摘要
Many applications need rpc to realize their business,in java world,we can choose rmi/webserivce to do rpc,but they’re not fast enough for most cases,so many of us choose some difference high performance network framework to realize rp

查看全文: http://www.udpwork.com/item/5709.html

+0  服务管理框架的尝试

Tag: 架构 | facebook | rpc | thrift
Tim 发于 2011年08月09日 22:58 | 点击: 1845 | 展开摘要
大型软件系统开发需要模块化,在分布式系统中,模块化通常是将功能分成不同的远程服务(RPC)来实现。比如可以用Java RMI、Web Service、Facebook开源的Thrift等一些技术。同样,在一个大型系统中,服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要。

服务管理目前并无直接解决方案,Thrift作者Mark Slee提到

It’s also possible to use Thrift to actually

查看全文: http://www.udpwork.com/item/5621.html

+0  序列化:serializable,hessian,protobuf性能对比

Tag: 小说&书评 | google protobuf | hessian | nio | rmi | serializable | xml-rpc
longhao 发于 2010年05月28日 15:01 | 点击: 5278 | 展开摘要
    分布式应用系统中,系统之间的通讯的质量决定了系统的可用性,当然很多可以选择的技术:XML-RPC,RMI,SOAP,CORBA,JMS,EJB,NIO等。在传输数据的过程中,数据包越小,占用的带宽就越少,同等条件下资源利用就会越小。目前基于SOA的ESB系统中,很多采用NIO来传输数据,就涉及到对象的序列化的问题。

    本文主要讨论jdk自带序列化,hessian,Google的protobuf之间的性

查看全文: http://www.udpwork.com/item/1548.html
|<<<1>>>| 一共1页, 10条记录