Q：越来越多Web 2.0网站走向应用平台，你认为打造这类平台的关键为何？
A：简单来看，应用平台就是API，任何Ajax或 Web 2.0类型的网站，都是在应用平台上运用了API来创造出视觉介面的互动效果。例如Yahoo Mail，透过简单的Request呼叫，来读取後续的信件。打造这类网站，如何规画解决问题的方式，会决定了网站未来的扩充性（Scalability），而非效能决定网站的发展。
Q：如何规画网站架构，才会具有扩充性？
A：将一个网站应用，分成几十个独立小程式，前端透过 API提供服务，後端是应用程式引擎，这样做自然会有扩充性。因为应用的每一个部分，都有不同等级的使用方式，需要有不同的扩充程度（scaling level），需要不同的机制来处理。以开发Yahoo Mail而言，是要开发一个地址服务程式丶一个读信服务丶一个送信服务，而送信程式完全和读信程式无关。以Yahoo的规模而言，需要让这些工作完全分离，才有扩充性。
Q：这种规画网站的方式，什麽是最重要的关键？
A：关键是你必须建立分离丶模组化的独立端点，而不是全部放在同一个大篮子里。大多数现今MVC架构（MVC framework）的开发框架（Framework），使用所谓的前端控制器（Front Control），每一次浏览器提出Request请求时，就会呼叫这个前端控制器，再由前端控制器来分辨，使用者想要执行哪一支程式。这样做，一点意义都没有。
在浏览器层次，程式完全能知道使用者想要做什麽事情，例如使用者只是要读信，程式就不用再把需求送到伺服器，让伺服器判断使用者要读信还是送信。将这类决策工作拉出浏览器，由伺服器处理，就会浪费大量伺服器资源，来处理那些对使用者没有实际功用的工作。扩充性来自架构，很多开发框架，将所有事情绑在一起，限制了架构。选错开发框架，你就没有扩充性。
Q：你是说MVC模式不利於网站扩充性？
A：MVC模式比较适合用在网页控制器（Page Control）的层次。基本上，每一个网页控制器都是独立模组，读信和查地址是不同的网页控制器，所以，读信程式就不会干扰到查地址程式。所以，在每一个端点使用MVC模式来打造小型的网页控制器，是不会有问题。但是，大多数采用MVC模式的框架，预设在网站中采用前端控制器，而非用网页控制器的方式，这样的MVC模式，只适合在小型或单一伺服器的网站。
Q：你会如何选择开发框架呢？
A：一个框架都不要用。但是，我会从这些开发框架中，找出我需要的功能，拿出那个我需要的程式模组来用，或者参考其中的设计想法，而不是套用整个框架。我所看到的大多数框架，都没有专注在打造有效能的扩充性和可模组性。
Q：难道开发者不需要框架或架构吗？
A：网站的确需要有架构，每一个人都需要框架，框架是一种解决问题的方法。但是你并不需要通用型框架，用一个前端控制器，来解决所有问题，这样通常没办法成功。每一个问题都不同，你需要引导框架，使用正确的设计模式，直接解决真正要处理的问题。只生产一款汽车，怎麽可能满足全世界人的需求！
用框架开发雏形系统就好，但真正的产品就不要全部套用。从框架开始比较容易，但你要拆开全部的框架，移除Runtime检查丶拿掉不需要的功能，只留下你会用到的程式模组。你不需要一个通用型框架，因为它无法提供未来的扩充性，但也不用重头写起，你需要的是介於两者之间。
Q：网站需要规画到多久以後的扩充需求？
A：我总是痛恨要帮未来考虑太多。当你无法预测未来，你就无法帮未来作决定。
网路变化太快，我通常只规画半年内的事情。现在决定半年以後的事情，可能会做出错误决策，反而让事情更糟。如果你没有解决当下的问题，而是想像未来会发生的问题，我认为不值得，我宁可解决眼前看得到的问题，真正聚焦在当下需要的产品。
Q：那麽，有任何准则是架构人员可以遵循的吗？
A：最主要的原则是，仔细考虑如何分配程式模组，尽可能将程式拆解成更小的元件，调校出适当的API，你应该规画的是使用者端点的事情，例如浏览器请求的类型是什麽？应用程式要如何回应？是否可以切割？是否可以把这些工作分配到完全分离的伺服器上执行？即使是在同一台伺服器上，你也能从使用者端点的角度来架构应用程式，有一天，当你的规模变大後，就可以很容易加入第二台伺服器，只要在前端伺服器不储存任何资料，就能进行流量分担。一般开发者最大的错误是，让程式码之间的交互关连（interrelation）太深，每个不同的元件都需要和其他外元件沟通，这样做很难调校出很乾净的API。开发者会无法抽离出效率慢的API放到辅助伺服器中，而让主要伺服器只执行必要API。
Q：切割服务丶拆解程式的难度是什麽？
A：必须在开始之前，就要非常了解问题。当你写完第一个版本的程式，才着手拆解问题，那几乎是不可能，很难事後处理。这的确很难，因为问题会一直改变。但是，若你从简单的架构开始，并且保持这个精神来区隔程式模组。每次当网站发生变化时，问题的变化也只会影响到一小部分，你就能够非常清楚那个地方，能够直接解决问题。就好像乐高游戏一样，盖好每一个小块积木，哪边还有不足，就只需要再补上一小块就好，不用对整体改变太多。
Q：除了扩充性以外，如何提高网站效能呢？
A：要提高效能，得先知道每一支程式花了多少时间。我会问，使用者送出Request请求後，要多久才会收到第一个Byte的资料？很多开发人员不晓得这个时间（First Byte Latency）是多久，不晓得自己的程式码用掉多少时间？可以透过Profile来追踪效能，画出视觉化的效能流程图，来了解瓶颈在哪。
甚至要考虑到单一机器上的延迟，透过系统层级的追踪程式，知道程式执行的每一个系统呼叫（System Call）耗费多久。还要考虑浏览器中的延迟，从使用者实际感受的速度来改善网页执行方式等。
每次你增加一个新功能，要能计算出新功能会增加多少毫秒，想一想这麽做值不值得。
Q：那麽，网站的安全性又需注意哪些原则？
A：基本精神很简单，只要用资料防火墙的概念来设计网站。网路防火墙会严密监控每一个通讯埠，只让没有安全疑虑的封包通过，但网站开发者刚好相反，只挡掉自以为有危险的内容。开发者不能信赖任何从外部取得的资料，借用防火墙概念和手法，建立资料防火墙，就能提高网站安全性。
Q：好的架构师需要什麽样的条件？
A：必须非常了解技术，了解每一个细节，例如设计资料储存机制，要了解哪种资料可以储存丶可以存多大的档案，放多少资料丶每秒钟可以放多快？如何复制资料？前端必须使用哪种资料格式等。架构师可以不用像 DBA，知道如何修复Oracle资料库的错误，但是要能够了解Oracle资料库拥有的能耐。这种人很难找，必须要失败过很多次，才会有足够的经验。
Q：台湾还有不少旧网站使用PHP 4，他们应该现在升级到PHP 5吗？还是等待PHP 6？
A：尽快升级到PHP 5。只要作一些测试和修改，就能得到更好的效能和安全，为什麽不做？不需等待PHP 6，开源社群的运作方式，无法承诺推出时间。很多新功能已经放到PHP 5.3版中，赶快从4升到5最重要。
comment créer un site Web
Code source du site Web
Comment ouvrir le fichier php
Comment bloquer un site Web
Comment supprimer les premiers éléments d'un tableau en php
Que faire si la désérialisation php échoue
Comment connecter PHP à la base de données mssql
Comment connecter PHP à la base de données mssql
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
