最新 | 最热门 | 最高评价
---

+0  Blog安全问题小记

Tag: Security | DDos | PHP | WordPress | XML-RPC Attack
四火 发于 2017年11月21日 03:50 | 点击: 2476 | 展开摘要
最近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 | 点击: 1729 | 展开摘要
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 | 点击: 2736 | 展开摘要
原文出处: 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 | 点击: 14780 | 展开摘要
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 | 点击: 2013 | 展开摘要
软件随想录（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 | 点击: 2153 | 展开摘要
针对在项目中碰到的一些容错设计问题，团队最近进行了一次技术沙龙，讨论了以下话题。

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

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

每个系统的可用性不可能达到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 | 点击: 6675 | 展开摘要
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 | 点击: 3264 | 展开摘要
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 | 点击: 2784 | 展开摘要
大型软件系统开发需要模块化，在分布式系统中，模块化通常是将功能分成不同的远程服务（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 | 点击: 6449 | 展开摘要
    分布式应用系统中，系统之间的通讯的质量决定了系统的可用性，当然很多可以选择的技术：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条记录