昨天折腾了1个小时，把5.2升级到5.3，目前是成功了，遇见了几个小坑。但是之后的坑不可预见，分享一下遇见的小坑。 前提是必须仔细阅读的官方文档。 刚开始的时候，改了composer文件，直接更新，出现了错误 Declaration of App\Providers\EventServiceProvider::boot() should be compatible with Illuminate\Foundation\Support\Providers\EventServiceProvider::boot(Illuminate\Contracts\Events\Dispatcher $events) 然后我去看了下官方文档，具体忘记在哪里了，主要是bootstrap里面的cache文件没有清理，所以必须得先清理，运行下面的命令 php artisan route:cache php artisan view:clear php artisan config:clear php artisan cache:clear php artisan clear-compiled php artisan optimize php artisan route:cache 更新完之后会报错， ErrorException in EventServiceProvider.php line 8: 按照官方文档解释，就是这些功能已经改变，不需要参数，所以，我们找到相应的位置，把参数去掉即可 public function boot() { parent::boot(); } from：https://laravel-china.org/topics/3767/upgrade-laravel-52-to-53
View Details这是一个Web Server的时代，apache2与nginx共舞，在追求极致性能的路上，没有最高，只有更高。但这又是一个追求个性化的时代，有些Web Server并没有去挤“Performance提升”这一独木桥，而是有着自己的定位，Caddy就是这样一个开源Web Server。 Caddy的作者Matt Holt在caddy官网以及FAQ中对caddy的目标阐释如下： 其他Web Server为Web而设计，Caddy为human设计。功能定位上，与经常充当最前端反向代理的nginx不同，caddy致力于成为一个易用的静态 文件Web Server。可以看出Caddy主打易用性，使用配置简单。并且得益于Go的跨平台特性，caddy很容易的支持了三大主流平台:Windows、 Linux、Mac。在Caddy开发者文档中，我们可以看到caddy还可以在Android(linux arm)上运行。caddy目前版本为0.7.1，还不稳定，且后续版本可能变化较大，甚至与前期版本不兼容，因此作者目前不推荐caddy在生产环境被 重度使用。 关注caddy，是因为caddy填补了go在通用web server这块的空白(也许有其他，但我还不知道)，同时Web server in go也“响应”了近期Golang去C化的趋势(Go 1.5中C is gone！)，即便caddy作者提到caddy的目标并非如nginx那样。但未来谁知道呢？一旦Go性能足够高时，一旦caddy足够稳定时，自然而 然的就会有人将其用在某些应用的生产环境中替代nginx或apache2了。一套全Go的系统，在部署、运维方面也是有优势的。 一、安装和运行caddy 和诸多go应用一样，我们可以直接从caddy的github.com releases页中找到最新发布版(目前是0.7.1)的二进制包。这里使用的是caddy_darwin_amd64.zip。 下载解压后，进入目录，直接执行./caddy即可将caddy运行起来。 $caddy 0.0.0.0:2015 在浏览器里访问localhost:2015，页面上没有预期显示的类似"caddy works!”之类的默认Welcome页面，而是“404 Not Found"。虽然这说明caddy已经work了，但没有一个default welcome page毕竟对于caddy beginer来说并不友好。这里已经向作者提了一个sugguestion issue。 二、caddy原理 Go的net/http标准库已经提供了http server的实现，大多数场合这个http server都能满足你的需要，无论是功能还是性能。Caddy实质上也是一个Go web app，它也import net/http，嵌入*http.Server，并通过handler的ServeHTTP方法为每个请求提供服务。caddy使用 http.FileServer作为处理 静态文件的基础。caddy的诱人之处在于其middleware，将诸多middleware串成一个middleware chain以提供了灵活的web服务。另外caddy中的middleware还可以独立于caddy之外使用。 caddy从当前目录的Caddyfile（默认）文件中读取配置，当然你也可以通过-conf指定配置文件路径。Caddyfile的配置格式 的确非常easy，这也符合caddy的目标。 Caddyfile总是以站点的Addr开始的。 单一站点的Caddyfile样例如下： //Caddyfile localhost:2015 gzip log ./2015.log Caddy也支持配置多个站点,类似virtualhost的 配置(80端口多路复用)： //Caddyfile foo.com:80 { log ./foo.log gzip } bar.com:80 { log ./bar.log gzip } 为了实现风格上的统一，单一站点也最好配置为如下这种格式(代码内部称之为 Server Block)： localhost:2015 { gzip log ./2015.log } 这样Caddyfile的配置文件模板样式类似于下面这样： host1:port { middleware1 middleware2 { … … } […]
View DetailsNeo4j是一个高性能的,NOSQL图形数据库，它将结构化数据存储在网络上而不是表中。它是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎，但是它将结构化数据存储在网络(从数学角度叫做图)上而不是表中。Neo4j也可以被看作是一个高性能的图引擎，该引擎具有成熟数据库的所有特性。程序员工作在一个面向对象的、灵活的网络结构下而不是严格、静态的表中——但是他们可以享受到具备完全的事务特性、企业级的数据库的所有好处。 Neo4j因其嵌入式、高性能、轻量级等优势，越来越受到关注.
View DetailsBeanstalk，一个高性能、轻量级的分布式内存队列系统，最初设计的目的是想通过后台异步执行耗时的任务来降低高容量Web应用系统的页面访问延迟，支持过有9.5 million用户的Facebook Causes应用。 后来开源，现在有PostRank大规模部署和使用，每天处理百万级任务。Beanstalkd是典型的类Memcached设计，协议和使用方式都是同样的风格，所以使用过memcached的用户会觉得Beanstalkd似曾相识。
View Details