当我们的 URL 地址返回的状态码是 400、403、404、500 的时候，跨域的资源是不会跟随返回的，也就是说，即便是 Nginx 上配置了 add_header 关键字，也不会随着内容返回而返回。

zipkin是一个开放源代码分布式的跟踪系统，由Twitter公司开源，它致力于收集服务的定时数据，以解决微服务架构中的延迟问题，包括数据的收集、存储、查找和展现。它的理论模型来自于Google Dapper 论文。

过去咱们开发中，对日志这个环节其实并不太重视，直到有一天，应用出现异常，这个时候才想起来“日志”，但很可惜，为时已晚。 咱们做运维和开发，除了救火，还需要防火，因此一些防范的意识也是非常重要的。 效果图 安装ELK 安装 ELK 是相对简单的，但是后期也需要对其进行优化，适当考虑运维人力，如果觉得个人可以折腾...

整个系统以 Graphite (carbon + whisper) 为核心, kong 通过 statsd plugin 将服务调用信息发送至 statsd, 而 statsd 则将统计信息通过 Web API 保存至Graphite . 最终在 Grafana 中通过 Graphite Data Source 获取统计信息并输出图表到面板.

我们总是听到编排这个词，所以我喜欢这张幻灯片 – 它展示了一个乐队，然后有个指挥家，下面一堆人（微型服务）演奏自己的乐器。这个指挥家（API网关）可以以某种方式来协调我们的架构如何处理请求。

随着业务增长，部署的机器可能会随着增长，增加配置难度和维护难度。配置会因为机器的增多而变得更加容易出错，为了解决这个问题，于是我们引入了 360 开发的 Qconf 来解决这个问题，目前已经稳定用于线上环境当中。

FastD 是一个专门针对 API 应用层而生的一个 PHP 应用框架，提供良好的中间件，路由以及支持 swoole 扩展运行，从而具体良好的性能条件。

我总感觉 PHP 的开发者们并没有对 PHP 的质量有所追求，可能是因为 PHP 的机制问题吧，让大部分的开发者总以为浏览器访问就没有问题，所以很多时候，做 PHP 开发的，就没有单元测试的这些概念了。能不能有点追求？

因为遇到了，当业务分布较广，配置分布较广的时候，就会很容易地出现一些问题，比如做了负载均衡，需要调整一下应用配置。刚好改漏了一台机，就偶尔出现一些问题，排查起来也是很吃力的。

从上个版本到目前，真个开发已经持续快一年了。这个项目我已经一个人维护了将近2年，陆陆续续陆陆续续地，发布了好几个版本，从0.1.0 的定稿版本 Dobee，到 fastd1.0， fastd2.0，到今天的3.0，经历了太多太多的迷茫与坚持。打心里地说，当时和现在，心态差别太多，每天都花时间去投入，感觉又没有看到回报，每当我去尝...

加过最晚的班，经历过最多人的团队，吃过最贵的饭，做过最多的功能，做过最复杂的架构，做过最艰难的抉择，法国最多的脾气，鬼知道我经历了什么。 要是绩效按照代码行数来算的话，估计可以达标。 2016年还有一个很突出的事，就是给了最多的份子钱，也算是一个突破吧。? 工作就平平无奇，还是老样子，虽然有各种的框架，...

打杂，扫地。负责部门大大小小的事务，大到方案制定与落实，小到吃饭喝酒大保健。但工作只是生活中的一小部分，当然我可不是一个普通的开发者，我还有好多自己喜欢做的事情，开发，只是其中一项。

其实应该更多的是互相的磨合与学习，希望身边的人可以有自己的经验分享，与理解，互相进步才是大家需要的，作为一个 "年老" (我也是90后) 的开发者，我觉得一代胜一代，未来才有胜算。额，好了，我不充当老师的角色了，去正题。

PHP 相关 FastD PHP Web框架 PHP路由 Swoole网络组件 PHPHttp解析组件 PHP数据库 PHP对象生成器 PHP错误处理组件 PHP配置 PHP命令行工具 PHP简单容器 PHP注释解析组件 PHP文件处理(基于symfony/finder) PHP数据存储 PHP日子处理(基于monolog) PHP模板引擎(基于twig) PHP中间件 PHP单元测试 HTTP 中间件 PHP 数据类型操作...

FastD 默认使用的是 twig，因此从前端来说，twigjs 和 fastd是可以整合的，而且并且试验过，twigjs和 fastd 整合也是前后端开发一个不错的方案。

我的 PHP 学习路线 1. PHP 入门 PHP 入门没啥好说的，会基本编码，基本的开发结构(通常指MVC，呵呵哒)，类与对象，就差不多了，可以说是入门了。 1.1 OOP 写 PHP 最多目前无非就是 OOP，面向对象，说时迟那时快。不开玩笑地说，与我共事的某些前辈是连 OOP 都搞不清的，这里我就不多说了。 其实不是说一定要会，要去理解...

URL（全名Uniform Resource Locator），又譯劃一資源定位器，俗稱網頁地址（網址），係互聯網上標準嘅資源嘅地址。要去互聯網上任何一個地方，都需要佢嘅URL。

我以前觉得，造一个框架，不是很难，其实我现在也是这么认为的，不是说我到底有多么厉害，其实我仅仅是觉得，造出来不难，恰恰是造出来之后，你要去 “养育” 它，这对我来说，则是最难的，我现在正是体会到了。

这个在工作中遇到的其中一个活生生的例子，因为 nginx 在编译安装的时候并没有考虑太多，而且我一向的做法都是按照项目需要安装相应的功能，尽量让服务和应用简洁。

额...我也不知道为何自己那么喜欢折腾。 自己想写一个网站，额，但是......现在有这么多的网站提供这样的功能，而且做得都比我好，我还有必要去自己造一个？ 项目练习？额，我觉得不是，因为我自己的能力和实力都可以做到，有必要花这个时间在上面，还是自己去学习其他？ 额，纠结，请叫我纠结帝

最近终于放下手头的一件小事了。就是本人的框架官网终于弄完了，哈哈。地址: fast-d.cn。大家多多指教。 fast-d 是以往 dobee + fast-d api 合并而来的。组件也全部更名为 fastd－components了 可以继续开展更多的学习了，酸爽。

Dobee php routing component. 框架路由组件 改玩意也是依赖composer的哟。 项目地址: github coding 由来 其实一开始不打算做这个东西的，因为现在到处都是，之前也讲过，本人也是一个爱作死爱折腾的人，所以还是参考了一些别人的，做了一下玩玩 安装 此玩意已经推托管到packagist了，用composer装逼的同学可以试试。但...

整个项目的来龙去脉，其实是来源于生活中的那个东西：乐高积木，小时候经常玩的一个玩具，乐高积木有啥特性哇？就是很多个部件，然后提供不同形状，凸点，凹点，自己自由组合，那么这些凸点和凹点其实可以相比作为平时开发当中的标准化"接口"，只要你的另外一个部件能够符合这个接口，就可以安装接入了。框架本身也参考...

过去一些学校老师每当讲到面向对象的章节，都会猫不犹豫的定义一些class(类)。那么，这就是面向对象了么？过去我也是这么认为的，但现在看来，其不然。

今天看了看 深入PHP++面向对象、模式与实践_第三版 其中看到“聚合”跟“组合”的概念，对此理解也比较模糊 文中是这样说的： 理解上面文本中的话，我个人理解是成这样： 首先是聚合 {代码...} {代码...} {代码...} {代码...} 类内聚了两个类：分别是agregationB, agregationC 分别都实现了AgregationInterface, 而且在实力A...

个人 Fast D 文档参考 Doctrine 2php specDoctrine DocumentSymfony cheat sheetHTTP API Design Guidepro git中文Swift 入门C Lang 工具资源 在线正则匹配PHPUnit手册Pjax 可以试试优化体验Nprogress 进度条packagist.orgphp-cassandraPHP-GOSSDBPHP SwooleEasyicon 专门搜索icon的网站web开发工具（不知道大家合适不，...