做不得旷世的逸才,只做你天地间的伞。
最近发表的话题
最近发表的评论
  • 变态的面试题目 at 3小时前

    这知识点远远超出了 PHP 的范畴,更何况是「初级 PHP」。

    感觉这类题目其实没太大意义,就好像当年 a+++--b*c = ? 之类的问题一样...

  • Laravel 无法保持长链接 at 11小时前

    测试了一下,感觉应该不是 Laravel 的锅。代码如下:

    // routes/api.php
    
    Route::get('/test', function () {
        echo("<html><body>");
    
        foreach(range(1,10) as $i) {
            echo str_pad($i,2048," ");
            @ob_flush();
            flush();
            sleep(1);
        }
    });

    命令行执行:

    php artisan serve

    随后打开 http://localhost:8000/test与原生 PHP 输出的效果无异。

  • Laravel 无法保持长链接 at 11小时前

    无法正常运行,具体的表现是什么呢?

    卡住,无法实时展示结果?

    或者是直接返回响应并关闭连接?

  • 公司项目,请问 Laravel 版本的选择 at 16小时前
    额外花一点点时间?哦吼?已截屏 靠你了😂😂😂
  • 公司项目,请问 Laravel 版本的选择 at 16小时前
    +10086
  • Laravel 项目抽离 vendor 目录的问题 at 1天前

    @Thinklong

    首先我们肯定是希望至少一个项目组使用的环境、版本都统一,也是规范化的其中一项吧,所以把lock和json及vendor统一在git上管理(最小颗粒是项目组统一),这样就不会出现lock文件管理和扩展包依赖的问题。

    vendor 绝对不应该进入版本管理,应当进入版本管理的是 lock,同一个 lock 安装出来的依赖应当是完全一致的。

    我非常赞同你所说的部署方案,但如果我有20台目标机需要部署,在目标机进行install会有很多问题,比如部署周期可能会比较长、其中一台install失败就得重新部署等等很多不可控的因素。

    在服务器上直接 composer install 也是可以的,但是就需要一套编排 / 部署系统来调度,如果遇到某台机器安装依赖失败,那么就不能把流量导向过去(不需要全部重新部署)。目前来看比较优秀的方案是 Kubernetes,很多国内厂也做了不少类似的轮子项目,你可以自行 Google。

    如果在部署机先install然后打包scp到目标机,部署机如果项目比较多,部署机会吃不消。

    其实没多少压力。composer install 主要就是网络流量的消耗,根据你的方案,这台「部署机」应当是个长期存在的实例,包含着每次依赖安装产生的 Composer global cache,而项目的依赖变动一般不会太大,所以每次 Install 其实没什么压力。如果是担心「部署机」到「目标机」的网络流量消耗的话,现在云服务商都有 VPC 功能,直接走内网即可。

    按照这个方案施行的话,我推荐一个工具:Ansible。

    最后,你提到的方案是「所谓部署机」 代码到「实际服务器」。如果有做 CI 的话,我还是更推荐 CI 上只打 Artifact 并上传到对象存储,随后通知「实际服务器」到对象存储 代码。

  • 当我承认自己写得不好时,反而能放心写作了 at 1天前

    十分赞成。

  • Laravel 项目抽离 vendor 目录的问题 at 2天前

    我不太赞成这么做。观点如下:

    1. 如何管理 composer.lock 文件?多个项目共享 vendor,那么它们的 lock 文件必须保持一致。暂时想不到什么好的解决方案能够比较容易地在多个 Git repo 内共享 composer.lock。
    2. 不得不保证所有项目依赖的扩展包版本全部一致,出现依赖版本冲突时无法解决;升级某一个扩展包将会直接影响多个项目。

    针对这个问题,以下是我觉得比较好的部署方案:

    1. 滚动部署,利用 Deployer 或者类似的方案(新创建一个副本、等待部署完成后,再将流量「导向」至新的副本)。
    2. 直接在 CI 上执行 Composer install,并打包 Artifacts。在服务器上直接下载带有依赖的 Artifact 压缩包并解压即可。
  • Laravel 项目抽离 vendor 目录的问题 at 2天前
    我比较支持 @fengzi91 的观点,你不应当在生产环境修改一个线上的服务,而是新创建一个副本、等待部署完成后,再将流量「导向」至新的副本。
  • @JeffLi 在 2019-08-15 17:27:02 的动弹 at 4天前

    微擎里面几乎所有的应用代码质量都很堪忧... 还是做点别的吧。

  • @ 吃鱼不吐刺 在 2019-08-17 10:23:18 的动弹 at 4天前

    你这个是 PR 吧。以下为猜测:

    1. 第一个 Merge branch ... 的 Commit 应该是你先 git commit,随后 git pull 时自动产生的 Merge commit。
    2. 第二和第三次 Commit 因为信息不全不知道是什么原因。
    3. 第四次 Commit 可能是因为你从 A 分支 Checkout 出来当前 C 分支,然后提交 PR 合并 C 到 B 分支;然而 A 分支还没有合并到 B 分支,所以导致带进来其它的 Commit。
  • Docker 搭建一套 PHP 的环境和直接在宿主机搭建 PHP 环境性能差别大么 at 4天前

    具体得看是什么平台。

    由于 Docker 容器化技术实际是通过 Linux namespaces 和 Cgroups 实现的,如果是 Docker for Windows / macOS 那就需要一套虚拟化技术,把你的电脑作为宿主机,运行一台 Linux 的虚拟机,最后再在虚拟机的内部运行 Docker Daemon 和应用本身的进程。这样就大大拖慢了性能。因此就会出现 @JaguarJack 提到的 MySQL IO 慢等问题。

    BTW, 吐槽一下... Docker for macOS 的 IO 是真的慢... 慢到怀疑人生。新版 Windows 似乎包含了 Linux 内核作为「子系统」,具体没有深入了解哈,不知道性能会不会有所提升。

    最后,在 Linux 的各大发行版上基于 Docker 运行应用,其实性能影响不大。Docker Daemon 并不是传统意义上的一台「虚拟机」,它并没有「虚拟」出一套完整的运行环境,容器内的进程与宿主机仍然共享同一个内核。

    我个人更喜欢把 Docker Daemon 看作是一个负责 管理 容器的 Side Car,而不是负责 承载 容器运行的「鲸鱼船」,它和容器内的进程在某些意义上来说是 平级 的。甚至如果激进一点,现在可以用类似 Podman 之类的项目代替 Docker Daemon,只需要有一个能帮你管理容器相关资源的东西即可。真正的应用容器启动之后,Daemon 什么的存不存在似乎并没有那么重要。

  • 客户要个 ‘记住密码’ 的功能,我该怎么办? at 4天前

    其实你就记住登录状态就好,只不过进入到登录页面后不自动跳转到应用主页,而是在登录页面显示 「*******」,让它以为是密码「被记住」了。

    😂

    灵机一动想到的,有问题别打我。

  • @hello-Laravel 在 2019-08-16 11:16:43 的动弹 at 5天前

    看一下注释,这个文件一般是由其它工具生成的;例如:resolv-confnetwork-managersystemd-resolvd。你需要根据提示修改对应工具的配置文件才可以。例如我的一台 Ubuntu 机器上的 /etc/resolv.conf

    # This file is managed by man:systemd-resolved(8). Do not edit.
    #
    # This is a dynamic resolv.conf file for connecting local clients directly to
    # all known uplink DNS servers. This file lists all configured search domains.
    #
    # Third party programs must not access this file directly, but only through the
    # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
    # replace this symlink by a static file or a different symlink.
    #
    # See man:systemd-resolved.service(8) for details about the supported modes of
    # operation for /etc/resolv.conf.
    
    nameserver 8.8.8.8
    nameserver 192.168.88.1

    This file is managed by man:systemd-resolved(8). Do not edit.

  • PHP 快速扫描列表创建无限极分类树 at 6天前
    @yzh52521 根据你极其匮乏的描述,我测试正常。
  • PHP 快速扫描列表创建无限极分类树 at 1周前
    无法理解你的意思,请具体说明。
  • PHP 快速扫描列表创建无限极分类树 at 1周前
    请问有发现什么逻辑问题吗?
  • @JeremyKuang 在 2019-08-14 11:16:54 的动弹 at 1周前

    不需要。

  • 国外服务器上的大文件下载速度很慢的问题 at 1周前

    可以试试 SCP,实在不行的话,或者挂个线路质量比较好的代理。用迅雷、VPS 什么的基本都不太靠谱。

  • 有什么能监控网站是否正常运行的软件,如果没法访问则邮箱通知 at 2周前
    • StatusCake
    • DataDog
    • Google StackDriver
    • NewRelic