CrazyCodes

前言架构是一款软件从0到100的演变过程。并非是上来就可以承载什么亿级访问的牛x架构什么的。本篇写给那些想要成为架构师或者正在尝试成为架构师的朋友。陕西的城墙有架构，阻挡外来攻击兵马俑黄陵有架构，避免根基倒塌这是硬性架构，在初期就应考虑清楚其稳定性。餐厅的人员配置，菜谱的交替更换以及管理的不断完善。这是软性架构，考虑扩展性。why为什么要做架构？有一部分人是这样说的做软件就需要架构没架构的软件不靠谱我是架构师这软件我必须做架构我在学习架构，所以我接手的项目要做架构各位.

前言以往写过俩篇文章[积德篇] 如何少写PHP "烂"代码https://blog.fastrun.cn/2018/08/15/1-51/举枪消灭"烂代码"的实战案例https://blog.fastrun.cn/2018/08/15/1-51/感觉文章中对Action的操作没有一个规范性的调用及编写。特此写了一个laravel-action包https://github.com/CrazyCodes/Laravel-Action希望可以帮到你。安装下载composer包: compo.

前言之前我写过一篇如何少写PHP "烂"代码 https://blog.fastrun.cn/2018/06/13/1-9/感觉很多新人对此不太理解。今天以打卡功能为例,去讲解其中的奥秘。那篇文章讲过代码开发的过程中分几种类型。增删改的需求Route -> Controller -> Service -> Action查的需求Route -> Controller -> Service -> Repository经过多次实际开发验证后，发现Reposi.

前言虽然程序员无时无刻都在造轮子，但造轮子也有效率之分，用好轮子才能造出好“????”guzzlehttp/guzzlecomposer require guzzlehttp/guzzle你可以用guzzlehttp完全取代curl,file_get_content,fopen等函数。这个扩展包使用起来极为顺手。我们在代码量上看下对比。php_curl<?php //初始化 $curl = curl_init(); //设置抓取的url curl_set

前言这是电商系统设计系列在商品设计这块的最后一篇文章。以下是其他文章地址，按照逻辑顺序排列如下电商系统设计之用户系统 https://blog.fastrun.cn/2018/06/14/1-10/电商系统设计之购物车 https://blog.fastrun.cn/2018/06/19/1-12/电商系统设计之商品 (上) https://blog.fastrun.cn/2018/07/08/1-26/电商系统设计之商品 (中) https://blog.fastrun.cn/2018/07.

前言我应该是少数在文章中直接展示接口文档的人。本篇我思考了很久到底要不要解析下商品接口开发的注意点。客户端开发与服务端开发即是天敌也是兄弟。希望本篇文章让你们减少争执，把“爱”给对方。接口设计简述电商系统设计之中，比较复杂的接口就论商品详情的接口了，响应参数特别多，特别杂。在开发获取商品详情接口时要遵循以下几个原则返回的JSON嵌套数量要少方便去查询到指定的SKU其他接口相关规范查询SKU关于查询SKU，我让我的小伙伴是这样做的，首先拿出规格和属性"选择颜色": [ {.

前言用户交易将经历一段艰辛的历程，一般用户感觉不到，实际程序是经历了一段生死离别。具体付款流程如下不(wo)是(gu)这(yi)张(chuan)图(de),请看正经流程图之前的几篇文章介绍了购物车如何设计用户系统如何设计商品系统如何设计其实他们都在为交易系统做铺垫，一个产品如果没有收入，那这只能是寺庙的公益产品。任何产品最终都要走向这步 (收钱)。付款用户付款过程中有很多场景也会出现意外，以下是我碰到的“天灾人祸”成功用户发起微信支付并成功支付用户发起支付宝支付并成功支付.

前言使用PHP,给定一个数,判断这个数是否是二的N次方这样看似简单的一个面试题, 实际牵出了很多基础知识,本章在为大家补习基础知识的情况下来解答这道题。先亮出答案function exponentiation($number){ if ($number < 0) { return false; } if (($number & ($number - 1)) == 0) { return true; } else { return false; }}.

电商大伙每天都在用，类似某猫，某狗等。电商系统设计看似复杂又很简单，看似简单又很复杂本章适合初级工程师及中级工程师细看，大佬请随意前言商品系统与订单系统(交易系统)是相铺相成的，当买家购买商品后将经历一个过程商品系统->交易系统->订单系统->物流系统->售后系统完成上述流程则是完成了一笔交易,经常网上购物的童鞋都懂这个。今天我们讲下从商品系统到交易系统和订单系统的存储过程及其设计上的应该注意的“坑”。存储前俩篇文章讲解的商品系统的SKU与SPU的设计过程..

电商大伙每天都在用，类似某猫，某狗等。电商系统设计看似复杂又很简单，看似简单又很复杂本章适合初级工程师及中级工程师细看，大佬请随意前言上一篇文章我们讲了关于电商SPU,SKU的概念,以及为何要设计自定义属性与自定义规格并解释了何时可以用到它们。我一直在说电商是一个既简单又复杂的东西,本章我们再一次深度解析电商系统商品设计的更多逻辑与实现。关联SPU对应多个SKU,SPU实际就是主商品表，类似于iphonex这款手机，而SKU则是这个商品绑定的规格表，类似与iphonex 红色款,iphon..

电商大伙每天都在用，类似某猫，某狗等。电商系统设计看似复杂又很简单，看似简单又很复杂本章适合初级工程师及中级工程师细看，大佬请随意前言商品的设计是电商系统中占据重要地位，如何设计出高扩展，高性能的商品系统并非一件简单的事情，我的设计是观摩互联网各大佬的设计后自行研究的，并非完全正确，但也不完全错误，现在我设计的这套电商系统已经在使用，如果在逻辑上遇到什么问题，会及时修改我关于电商系统相关文章的设计思想部分。元素见上图，本次我们先讲解下系统规格与自定义规格、系统属性与自定义属性的关于及其他..

基于 https://laravel-china.org/docs/dingo-api/2.0.0 文档更简洁的描述Dingo，直戳重点，注重实践概述Dingo API帮助您轻松快速地构建自己的API。虽然这个方案的目标是尽可能保持灵活性，但它仍然不能涵盖所有情况并解决所有问题。安装将以下代码加入到composer.json中，并执行composer update 或 composer install"require": { "dingo/api": "2.0.0-alpha1"}..

这是我整理的一套面试题,老铁们看看就当复习了哦概述感觉现在发面试题有些冷门，就跟昨天德国那场似的，不过看看当提前复习了。提前备战。这2个月出门面试的童鞋可注意不要中暑哦。说几个你所知道的设计模式单例模式保证一个类仅有一个实例，并提供一个访问他的全局访问点例如框架中的数据库连接 - 类似DB类策略模式针对一组算法，将每一个算法封装到具有共同接口的独立的类中，例如进入个人主页时，根据浏览者的不同，给予不同的显示与操作 - 类似不同用户呈现不同效果注册模式提供了在程序中有条理的存放并管..

本章适合初级工程师及中级工程师细看，大佬请随意前言问 [不存价格字段不行吗？直接查询商品表获取价格]答 [如果价格更新，应提示用户，商品的浮动信息。可以选择直接更新购物车，或者单独建立一个表，来记录更新的价格和信息，类似京东]问 [联表查询可以从商品表中知道商品是否上架]答 [商品不存在了如何联，只会将逻辑整复杂，未来包括降价提醒，无货提醒，下架提醒，购物车该如何查询就成了一个问题]上一篇文章在对于购物车业务及数据表设计中，有位童鞋在评论区与我讨论许久，特此独立一篇文章来详解下我的想..

电商大伙每天都在用，类似某猫，某狗等。电商系统设计看似复杂又很简单，看似简单又很复杂本章适合初级工程师及中级工程师细看，大佬请随意前言设计以以下为工具讲起PHP为开发语言基于Laravel框架MySQL为数据存储电商的可变性与孩子的心情一样，变化极快，所以在设计之处就要想好大部分的功能接入及开发，尽量减少重构次数。对老板来说节约成本，对程序员来说“珍惜生命”数据表前期业务简单时，我们可以将数据表设计为下列的样子TableNameCommentsmember..

写给初生牛犊不怕虎的童鞋们,大佬可随意摘看本章基于PHP Laravel前言经常会有人问目录如何设计比较好？代码如何分布好？怎么写一个可维护的项目?“烂”项目我也没少写，以下是参考互联网各大佬的文章总结及个人开发经验而来.ControllerController顾名思义是控制器，在入门PHP的时候，就知道Controller代表MVC中的C层，MVC本身的概念就代码分离，教你如何如何将业务分开，但面临着业务的不断发展，代码的复杂度也随之提高，功能与功能之间的链接错综复杂，最后你..

收到一个朋友的求救，他现在遇到一个难题。就是刚刚入职的公司，项目没有GIT,用的老版本的TP,CI，代码也很凌乱，目录也是非常的多，有的没的都在服务器上放着，服务器上还有将近30G的用户头像存着，总之就是一个字 “乱”我准备对这个乱到无法整理的公司项目、服务器及架构进行重新整理，接下来，请看我的表演～备份既然没有git，那就不用git了，直接在线上打包，ftp链接上下载，在毫无头绪的情况下，我建议直接重装。。如果你没有十足把握，建议不要送死。公司业务总结构新接口应用程序后台应用程序老接口应

服务治理所治理的服务需要合理的部署与管理，本章我们讲一下SOA(面向服务架构),本人语言文笔不好，所以本章内容使用问答模式，参考了 [SOA面试题(http://www.jdon.com/soa/soa-interview.html)] 的面试题,通过对此站复杂的描述进行简单的讲解。概述SOA代表了面向服务架构，仅仅是一种概念，通过这种概念而演变出的各种各样的服务架构都可称为SOA架构，SOA核心的概念就是 “松耦合”。非SOA的架构多语言开发同语言开发服务与服务之间可能会是不同的开发语言或

概述什么是队列？百度百科是这样说的“队列”是在传输过程中保存数据的容器。举几个生活中例子：iphone手机新款发布，三里屯iphone进的新货。大家要排队买，不能说一大堆人一起冲进去，那么这店就完了。你有一大堆女朋友。你不得一个一个来，一起来你也受不了 ?C语言中堆的概念也是这样，先进先出，不能起个大早赶个晚集。回到正题：消息队列则是为大批量处理数据而准备的一个概念，他有很多实现方式，并不是单一的代码结构。这里有比较专业的一篇文章：http://www.cnblogs.com/