创建Composer依赖包

很多新人小朋友都很好奇,怎么 composer require 一个依赖包就可以安装到项目里面了呢?那么今天,我就教大家怎么制作自己的依赖包,让其他小伙伴也能应用到自己的项目上 (注: 首先自己的依赖包一定要有质量保证。) 创建项目 进入自己想做成依赖包的项目中: composer init,一直往下,直到 composer.json 文件创建完毕,也可以自己创建 composer.json 文件,文件内容如下: { "name": "janhuang/ »

如何理解开发中版本的意思x.y.z

Version 的定义是日常开发中必不可少的意见事情之一了,但往往很多人会很容易忽略他其中的一些意义,导致很多时候,分支混乱,版本混乱,后期维护成本高的情况,这种情况取决于怎么去定义咱们的版本,怎么去使用咱们的分支。在拥有良好的定义,清晰的结构与说明的情况下,是可以减少大部分让人头疼的细节问题,版本是其中的一个。 在业界,其实细心地朋友不难发现,有很多的很详细的解析,可能我写这一篇博客也是多次一举,完全可以引用网上的案例与解析。 首先说说github上面的一些开源软件的版本。 Alpha: 是内部测试版,一般不向外部发布,会有很多Bug.一般只有测试人员使用。 Beta: 也是测试版, »

FastD 构建服务发现初探

今天来分享的是如何用 FastD 去构建自己的服务架构体系,其实 FastD 的定位是API,提供数据。那如果抛开其他的因素去思考什么是服务的话,我会觉得服务的本质也是给外部提供数据。所以其实可以将 FastD 理解为就是一个单点的服务,从他本身部署的那一刻开始,他就算是一个对外提供数据的服务了。 基于 FastD 与 swoole 的优势,在使用 FastD 去做一些服务的时候,会显得尤为简单,并且现在周边的组件和插件已经有提供使用。 架构概述: Server提供服务, »

FastD+Nginx应用部署入门

本章节案例使用 fastd-demo 作为演示参考。 PHP 的好处就是快速,框架本身也没有摒弃这种理念,玩的就是高效。 环境: ubuntu/centos nginx/openresty php7.1 fastd 3.2 swoole 1.9.x redis 3.x mysql 5. »

FastD 架构应用场景预告

目前市面有很多的框架,组件,各有所长,结合FastD在企业中的应用场景,打算对 FastD 的一些实践场景与一些其他系统配合做一个简单的分享。 有如下分享整理: FastD 与 Nginx 的结合 FastD 服务发现一: 初稿 FastD 缓存穿透等问题处理 FastD 应用监控与日志分析 FastD 如何利用事件进行逻辑处理 FastD 健康检查 FastD 与消息队列 FastD »

Nginx CORS跨域

场景 我们的资源来自网络的四面八方,所以难免需要用上跨域,业界也有非常多跨域的解决方案,这次我是来说说跨域与状态码之间的一个问题。 问题 当我们的 URL 地址返回的状态码是 400、403、404、500 的时候,跨域的资源是不会跟随返回的,也就是说,即便是 Nginx 上配置了 add_header 关键字,也不会随着内容返回而返回。 举个例子说: add_header »

浅谈RESTful API

大家都在讨论如何设计 RESTful API,我也来谈谈我对API设计的一些想法。 迄今为止,我个人认为,API设计较为好的是 github,可以去看看 github 的设计,点击这里。 我个人认为,想要设计好一个好看,易理解的API,首先得自己理解,而最基本的,应该是 url 的意义了吧,我相信,很多人都不完全知道 url 到底是啥,代表什么,仅仅是知道, »

FastD最佳实践五: 创建ELK日志分析

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

FastD最佳实践六: 创建Zipkin调用链监控

zipkin是一个开放源代码分布式的跟踪系统,由Twitter公司开源,它致力于收集服务的定时数据,以解决微服务架构中的延迟问题,包括数据的收集、存储、查找和展现。它的理论模型来自于Google Dapper 论文。 为什么要使用 zipkin 随着业务发展,系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成,当整个请求变慢或不可用时,我们是无法得知该请求是由某个或某些后端服务引起的,这时就需要解决如何快读定位服务故障点,以对症下药。于是就有了分布式系统调用跟踪的诞生。而zipkin就是开源分布式系统调用跟踪的佼佼者 安装 zipkin wget -O zipkin.jar »

FastD最佳实践四: 创建可视化监控

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