Month: 一月 2019

2018安全的PHP系统构架指南

The 2018 Guide to Building Secure PHP Software!

前言

2018 年将至,一般程序员(特别是 Web 开发程序员)应当抛弃过去开发PHP程序的很多不好的习惯和观念了。虽然部分人不以为意,但是这确实是事实。

这个指南应该以重点部分作为 PHP: The Right Way 安全章节的补充,而不是以一般的 PHP 编程话题。

正文

PHP 版本

请在 2018 年使用 PHP 7.2, 并且计划 2019 年初切换到 PHP 7.3。

PHP 7.2 已于 2017 年 11

        

IaaS,PaaS,SaaS 的区别

越来越多的软件,开始采用云服务。

云服务只是一个统称,可以分成三大类。

  • IaaS:基础设施服务,Infrastructure-as-a-service
  • PaaS:平台服务,Platform-as-a-service
  • SaaS:软件服务,Software-as-a-service

它们有什么区别呢?

IBM 的软件架构师 Albert Barron 曾经使用披萨作为比喻,解释这个问题。David Ng 进一步引申,让它变得更准确易懂。

请设想你是一个餐饮业者,打算做披萨生意。

你可以从头到尾,自己生产披萨,但是这样比较麻烦,需要准备的东西多,因此你决定外包一部分工作,采用他人的服务。你有三个方案。

(1)方案一:IaaS

他人提供厨房、炉子、煤气,你使用这些基础设施,来烤你的披萨。

(2)方案二:PaaS

除了基础设施,他人还提供披萨饼皮。

你只要把自己的配料洒在饼皮上,让他帮你烤出来就行了。也就是说,你要做的就是设计披萨的味道(海鲜披萨或者鸡肉披萨),他人提供平台服务,让你把自己的设计实现。

(3)方案三:SaaS

他人直接做好了披萨,不用你的介入,到手的就是一个成品。你要做的就是把它卖出去,最多再包装一下,印上你自己的 Logo。

上面的三种方案,可以总结成下面这张图。

从左到右,自己承担的工作量(上图蓝色部分)越来越少,IaaS > PaaS > SaaS。

对应软件开发,则是下面这张图。

SaaS 是软件的开发、管理、部署都交给第三方,不需要关心技术问题,可以拿来即用。普通用户接触到的互联网服务,几乎都是

            

PHP 7.4 新特性

PHP 7.4 新特性

PHP7.4 新增加了一些非常给力的新特性。在未来很长一段时间内,这无疑是一个非常重大的版本升级。

PHP 7.4可能会在2019年12月发布。此页面将同时定期更新。最后更新时间:2019.2.24.

 

预加载 

预加载是PHP核心的一个惊人的补充,可以带来一些重大的性能改进。

简而言之:如果您今天使用的是框架,则必须在每次请求时加载和重新编译其文件。预加载允许服务器在启动时在内存中加载PHP文件,并使它们永久可用于所有后续请求。

性能提升当然需要付出代价:如果预加载文件的来源发生变化,则必须重新启动服务器。

此特性可以大幅提升IO性能,性能提升约30-50%,甚至更高。

类属性类型声明 

类变量可以加类型提示:

class A
{
    public string $name;
    
    public Foo $foo;
}

此RFC已被接受,并在PHP7.4 中实施。

 

协变返回和逆变参数

我以前写过PHP的类型系统,所以很高兴看到一些改进实际上是在PHP的核心。

类型变化 简而言之:你将能够使用协变返回类型......

class ParentType {}
class ChildType extends ParentType {}

    

讲讲PWA

一、背景

文章2017 前端大事件和趋势回顾,2018 何去何从?中提到了2017年前端值得关注的十大事件,其中就提到了PWA。

大家都知道Native app体验确实很好,下载到手机上之后入口也方便。它也有一些缺点:

  • 开发成本高(ios和安卓)
  • 软件上线需要审核
  • 版本更新需要将新版本上传到不同的应用商店
  • 想使用一个app就必须去下载才能使用,即使是偶尔需要使用一下下
                    

我必须得告诉大家的MySQL优化原理

说起MySQL的查询优化,相信大家收藏了一堆奇技淫巧:不能使用SELECT *、不使用NULL字段、合理创建索引、为字段选择合适的数据类型..... 你是否真的理解这些优化技巧?是否理解其背后的工作原理?在实际场景下性能真有提升吗?我想未必。因而理解这些优化建议背后的原理就尤为重要,希望本文能让你重新审视这些优化建议,并在实际业务场景下合理的运用。

MySQL逻辑架构

如果能在头脑中构建一幅MySQL各组件之间如何协同工作的架构图,有助于深入理解MySQL服务器。下图展示了MySQL的逻辑架构图。

MySQL逻辑架构,来自:高性能MySQL

MySQL逻辑架构整体分为三层,最上层为客户端层,并非MySQL所独有,诸如:连接处理、授权认证、安全等功能均在这一层处理。

MySQL大多数核心服务均在中间这一层,包括查询解析、分析、优化、缓存、内置函数(比如:时间、数学、加密等函数)。所有的跨存储引擎的功能也在这一层实现:存储过程、触发器、视图等。

最下层为存储引擎,其负责MySQL中的数据存储和提取。和Linux下的文件系统类似,每种存储引擎都有其优势和劣势。中间的服务层通过API与存储引擎通信,这些API接口屏蔽了不同存储引擎间的差异。

MySQL查询过程

我们总是希望MySQL能够获得更高的查询性能,最好的办法是弄清楚MySQL是如何优化和执行查询的。一旦理解了这一点,就会发现:很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。

当向MySQL发送一个请求的时候,MySQL到底做了些什么呢?

MySQL查询过程

客户端/服务端通信协议

MySQL客户端/服务端通信协议是“半双工”的:在任一时刻,要么是服务器向客户端发送数据,要么是客户端向服务器发送数据,这两个动作不能同时发生。一旦一端开始发送消息,另一端要接收完整个消息才能响应它,所以我们无法也无须将一个消息切成小块独立发送,也没有办法进行流量控制。

客户端用一个单独的数据包将查询请求发送给服务器,所以当查询语句很长的时候,需要设置max_allowed_packet参数。但是需要注意的是,如果查询实在是太大,服务端会拒绝接收更多数据并抛出异常。

与之相反的是,服务器响应给用户的数据通常会很多,由多个数据包组成。但是当服务器响应客户端请求时,客户端必须完整的接收整个返回结果,而不能简单的只取前面几条结果,然后让服务器停止发送。因而在实际开发中,尽量保持查询简单且只返回必需的数据,减小通信间数据包的大小和数量是一个非常好的习惯,这也是查询中尽量避免使用SELECT *以及加上LIMIT限制的原因之一。

查询缓存

在解析一个查询语句前,如果查询缓存是打开的,那么MySQL会检查这个查询语句是否命中查询缓存中的数据。如果当前查询恰好命中查询缓存,在检查一次用户权限后直接返回缓存中的结果。这种情况下,查询不会被解析,也不会生成执行计划,更不会执行。

MySQL将缓存存放在一个引用表(不要理解成table,可以认为是类似于HashMap的数据结构),通过一个哈希值索引,这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息计算得来。所以两个查询在任何字符上的不同(例如:空格、注释),都会导致缓存不会命中。

如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表,其查询结果
都不会被缓存。比如函数NOW()或者CURRENT_DATE()会因为不同的查询时间,返回不同的查询结果,再比如包含

        

一篇文章帮你了解 PHP 7.3 更新

file

PHP 目前依旧是其它脚本语言强劲的竞争对手,这主要归功于其核心维护团队的快速更新。

自从 PHP 7.0 发布以来,社区见证了许多新特性的诞生,极大地改进了开发者在项目中应用 PHP 的方式。提高 PHP 应用的性能和安全性,是这些改进的主要目的。

PHP 最近实现了又一个里程碑 —— 发布 PHP 7.3。新版本带来了一些急需的更新。

在本文中,我将论述新推出的 PHP 7.3 特性 和更新。好消息是,你可以在你的测试服务器上自行安装新版本、查看新功能。但老生常谈,切勿在生产服务器上使用 RC 版本更新,可能会破坏你已经上线的应用。

以下是7.3版中引入的一些更新,与以前的版本相比,它们大大提高了 PHP 7.3 的性能 。

  • 灵活的 Heredoc 和 Nowdoc 语法
  • 函数调用时允许尾随逗号
  • JSON_THROW_ON_ERROR
  • PCRE2 迁移
  • list() 分配参考