本文探讨了在业务优化中如何利用面向对象的继承特性来避免代码重复和提高可维护性。举例说明了异步处理在邮件发送、图片裁剪等场景的应用，强调了异步思想的重要性。同时，提到了静态化专题页面以应对高并发，并讨论了业务解耦对于提升效率和架构灵活性的价值。最后，简述了分布式和SOA在系统扩展中的角色，特别是自定义socket传输协议在跨平台性中的考虑。
业务优化
非侵入式扩展开发
比如原来有一个model，叫问答，现在需要开发一个有奖问答，需要支持话题打赏，里面多了很多功能。这个时候应该利用面向对象的继承的特性。而不是做下面的开发<?php
class AskModel {
public function detail($id){
$info = 从数据库查询到该问题的信息;
// 逻辑1
// 逻辑2
}
}<?php
class AskModel {
public function detail($id){
$info = 从数据库查询到该问题的信息;
// 逻辑1
if($info['type'] == 2){
//...
}else{
}
// 逻辑2
if($info['type'] == 2){
//...
}else{
}
}
}
这样逻辑多了，子类型多了，逻辑判断就非常重复，程序运行起来低效可能是一方面，更多的是不可维护性。
业务和架构不分家，架构是建立在对业务的理解之上的。再放下上次直播的PPT (sf故障无法传图，等会补吧)
异步思想
举例：处理邮件发送。
gearman 图片裁剪。
页面上 ajax 加载动态数据。
图片的懒加载，双击图片看大图。
sf 上通过websocket 通知你有新的消息，但是并没有告诉你有什消息，点击消息图标才会去异步请求具体的消息。
这些都是异步的思想。能分步走就分步走，能不能请求的就不请求。
静态化
专题页面，比如秒杀页面，为了应对更大的流量、并发。而且更新起来也比较方便。
业务解耦
比如刚刚上面说的专题页面，还有必要走整个框架的一套流程吗？进来引用一大堆的文件，初始化一大堆的东西？是不是特别低效呢？所以需要业务解耦，专题页面如果真要框架(可以首次访问之后生成静态页面)也应该是足够轻量级的。不能与传统业务混为一谈。
分布式以及 soa
说业务优化，真的不得不提架构方面的东西，业务解耦之后，就有了分布式和soa，因为这在上次分享中已经都说过了，就不多说了。
只说下 soa 自定义 socket 传输协议。
最重要的就是在自定义头里面强调body_len，注意设置为紧凑型，才能保证跨平台性 具体说明：https://mengkang.net/586.html
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
