创建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 »

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 获取统计信息并输出图表到面板. 这是网上找到的, »

FastD最佳实践三: 创建API网关

构建完成 API 服务,配置中心之后,架构图大致如下: 我们为何需要网关 引用 别人 的一句话: 我们总是听到编排这个词,所以我喜欢这张幻灯片 – 它展示了一个乐队,然后有个指挥家,下面一堆人(微型服务)演奏自己的乐器。这个指挥家(API网关)可以以某种方式来协调我们的架构如何处理请求。 我们需要将业务或服务放置在网关背后,由网关统一处理请求入口,本身由多个入口的处理变成了一个入口,由网关进行统一调度。 有一个很nice的事情,就是API网关让我们的客户端不用再需要知道和关心模块的地址(address) »

FastD最佳实践二: 创建配置中心

过去专门做了一篇文档来构建配置中心,基于 zookeeper 的配置中心。 环境要求及构建步骤可参考: QConf搭建配置中心 随着业务增长,部署的机器可能会随着增长,增加配置难度和维护难度。配置会因为机器的增多而变得更加容易出错,为了解决这个问题,于是我们引入了 360 开发的 Qconf 来解决这个问题,目前已经稳定用于线上环境当中。 安装 qconf 扩展包 composer require fastd/qconf-service-provider -vvv 扩展包有点特殊, »