""""
producter :YAO zhang
""""
**************************
    版本：v1.0
**************************
    如需修改请test
**************************
    全局的配置可以在default_settings进行
**************************
    环境有三种环境：
    dev:测试环境
    prod：生产环境
    stag：预发布环境
**************************
    参考来源：tencent运维框架
**************************
    代码规范要求

1.书写遵循Python之禅
2.命名规范
3.业务解耦
4.注释分明
5.单元测试通过
6.其他

**************************

文件目录说明

|____demo                           # project
| |____logs                         # 日志
|____doc                            # 说明
|____manage.py                      # 启动入口
|____requirements.txt               # 需要安装包
|____scripts                        # 外部脚本
|____teat_demo                      # 项目内部
| |____apps                         # 应用集
| | |____home                       # 应用
| | | |____admin.py                 # 后台register
| | | |____apps.py                  # 引用register
| | | |____forms                    # 验参
| | | | |____home_form.py           # 方法
| | | |____manger                   # model manger
| | | | |____user_manger.py         # 方法
| | | |____migrations               # 迁移文件
| | | |____models.py                # 模型类
| | | |____proxy                    # 模型类代理
| | | |____resource.py              # tastypie 书写参考
| | | |____serializer.py            # 序列化器
| | | |____template                 # 模板
| | | | |____context_processors.py  # 模板中间件
| | | |____templates                # 渲染模板
| | | | |____home                   # 渲染模板位置
| | | | | |____home.html            # 对应应用的模板
| | | |____tests.py                 # 单元测试
| | | |____urls.py                  # 调度器
| | | |____views.py                 # 视图
| |____base_model                   # 模型基类
| | |____base_model.py              # 方法
| |____conf                         # 配置
| | |____database.py                # 数据库配置
| | |____default.py                 # 默认配置
| | |____dev.py                     # 测试环境
| | |____pro.py                     # 生产环境
| |____core                         # 统一方法
| | |____exceptions                 # 异常处理
| | | |____base.py                  # 方法
| | | |____middleware.py            # 中间件
| |____db.sqlite3                   # Django内置库
| |____logs                         # 日志配置
| | |____log.py                     # 方法
| |____settings.py                  # 项目配置
| |____urls.py                      # 主调度器
| |____wsgi.py                      # Uwsgi配置

**************************
格式化工具可以考虑使用PE8的规范，或者第三方库
**************************
文档书写的话建议代码规范后使用第三方来自动生成即可，
减少开发的时间
**************************
ELK => Elsearchstatic Logstash Kibana
ES 可以通过Docker来部署，部署简单，有对应的文档<支持集群>
Kibana可以解耦ES放在另一台服务器或者容器来实现，修改配置文件指定ES的部署IP<支持集群>
Logstash 这个部署需要的环境<java,jdk,jdbc>较多，<类似日志收集>
注：ES和Kibana的版本要保持一致，
Logstash对java的JDK版本有一定的要求，
另注：关于ES7.X以上会附有java相关的环境
**************************
ES 使用到的库 elasticsearch_dsl
关于详细的使用可以参考官方文档
**************************
项目中md 里面是测试中间件的样板
如果需要添加中间件可以派生出来不同场景的中间件来指定即可
关于派生的实例可以参考异常处理的中间件的方法
**************************
关于自定义信号使用：
先说一下django内置的信号，信号有点类似于钩子方法
所以可以做一些预防处理或者事后通知的处理等等，
比如拿Es来说，某个人更新了DB里的Index那么是否也要修改Es里面Document对应的Index
如果在写一个独立的方法不如在对应保存的DB里面添加一个信号，一旦保存到DB就触发信号更新Index
详情可以参考官方文档
**************************
plugins 和src/plguins 里面内容暂时用不到，暂且不用过问，
该内容主要是实现插件化的开发
**************************
关于导包的顺序要求
>>>>第一：内置的包
>>>>第二: 第三方的包
>>>>第三: 自定义的包
关于命令的规范要去
比如: ClassName 类名驼峰式 :: 命名是一群一类的统称
get_hosts_ip 模块名       :: 命名是比较详细的一个动作
conf 包名                 :: 命名是内部所有文件的一个缩写<DOC==document>
**************************
MVC 的规范《Django》
FBV ::  装饰器规范请求方式
        异常统一中间件处理
        校验通过Form来完成
        M层处理DB相关的动作
        尽量使用钩子方法、信号、中间件、装饰器等
CBV ::  
    DRF 通过序列化器来完成校验
        M层和管理器同FBV一样处理
    原生 Form可以完成参数的校验
        合理使用装饰器、中间件等<同上>
Golang
>>> M层 只处理M层的问题:::sturct 结构体 映射DB——table
>>> C层 只处理M和V层的桥接:::参数的接受和格式的返回
>>> V层 只处理router注册，
>>> 合理使用中间件、钩子方法、Chain、Struct、绑定等

Vue
>>> 合理化组价分类和注册，根据情况实现全局和局部注册
>>> 参数的校验要配合前后端一起实现
>>> 前后端完成接口的测试，减少上线的风险
>>> 组件可以参考element和BK_ui等来方便开发等

**************************
关于基于SOA上个人的一些架构思想
基于：可拓展 伸缩性 安全性 可靠性 可定制

同时思想来源小霸王，
原因归于：：小时候小霸王可以根据不同的卡加载不同的游戏那么小霸王可以有多个，卡也可由多个也就是多对多的形式
一个小霸王可以满足2-4个人玩，那么10小霸王就是满足20-40个人玩，横向的拓展性实现，当然可以适当做缩减等来完成
伸缩性，关于可靠、安全、定制，就比较好实现了，首先可靠就是保证游戏在玩的过程中不会出现死机等等，安全保证
小霸王不会中毒，定制可以根据不同的玩家的爱好来开发不同的卡即可

OK说一下关于架构的实现的个人思路

首先以一台主服务器为主来说，所有API都有主的服务器来处理，在这里有两种方案
第一种：通过模块分离在分层来实现，首先每个模块做成服务，通过主服务来调用不同服务的API接口来实现不同的功能
第二种：同时完成分离情况下在实现分层，通过主服务根据不同的路由分配然后调用不同的服务，服务里面不做任务功能处理
仅仅只是做的路由的分发，然后对应的功能通过队列来实现<MQ_RPC>，然后对应服务模块再做RPC来分层到不同的服务器
综合另一种基于第一和第二来实现，首先不同模块分成后之后然后再对应服务中使用队列来实现那么实现

那么拓展可以主服务器做集群，Nginx做负载，CDN做缓存，拓展伸缩性 安全性可靠性，定制性
DB可以做分布式集群， 拓展性
NoSQL可以做集群哨兵，拓展性
ELK实现检索，ES可以使用集群拓展 拓展性
Sentry 实现异常信息检索
Kafka_zookeeper 集群 完成数据<分布式>队列
MQ 集群完成分布式队列
FastDFS和HDFS 分布式存储
Celery 异步 分布式实现

其他相关
IM 即时通讯 等开发相关的技术
监控工具:Kibana\Flowers\Redis_manager\MQ\....等等
测试工具:Jmeter\测试用例\单元测试\....等等
运维工具:Docker\Etcd\....等等

关于详细实现比如一个下单的接口来说
下单接口需要用到的
1.API 接口名称做路由分配
2.对应的DB
3.对应的业务逻辑

三层:应用层，数据层和服务层
通过API找到对应的子应用，之后完成参数校验，然后开始调用队列来传输，队列选择可以考虑分布式队列MQ_RPC和Kafka都可以
然后这里注意的是要保证业务处理模块和应用API层之间的传输肯定要定义一个规则，然后把参数按照规则拼接之后发送到队列里
队里可以根据个人做Exchang-bingkey-channle不同的管道来增加并发和吞吐量，之后服务层来处理所有的逻辑，也就是下单中
需要做的逻辑，同时过程中会调用不同的DB，调用可以通过RPC等等都可以，解耦了业务，路由，和数据，如果业务更换模式。或者
更换语言都影响不大，只需要按照传输定义的规则来实现即可，当然业务层到数据层也是一样，如果对应的DB不打算用了，但是一定
要安装同样的规则即可，即完成了所有的模块都拥有可代替性，同时接着演变成不同的服务，再细分的话就是业务分层了，把业务
细分到粒，同一属性的粒归属于一个团队维护即可，如果前期考虑到成本那么可以考虑Docker容器化来实现不同的服务，简称微服务
当然成本非常大，业务一旦细分之后可能会出现上百个服务，那么维护和部署起来是相当的麻烦，所以部署发版的时候要做好充足的准备
可以由1到100的来实现完成部署，保证部署中的风险缩减即可，以上为简述个人的架构思想

总结：当然开发中需要的工具会更加多，这个还是根据需求和业务有关，不同的架构不一定要按照同样的架构来实现，而是找到一个真正的
适合自己的架构，每一个好的架构都是根据项目的业务演变过来的，不可能一个小公司上来搞上百台服务器业务还没有就去考虑的话，那么
就是大炮打蚊子，没有任何必要，不如把更多的精力放在业务上以及功能实现优化上

**************************