PHP发明人谈MVC和网站设计架构 貌似他不支持php用mvc
程序员文章站
2022-06-02 16:07:13
...
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最重要。
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最重要。