架构

Danger

在实际工作中，选择稳定版时，尽量避免使用最新的版本，选择比已出来的最新版晚6～10个月的版本比较好。

工作开发和运维的统一原则为降低耦合度化繁为简是优秀的运维工程师必须掌握的重要技术思想

经常查看各种服务运行日志是一个很好的习惯，也是成长为高手的必经之路

代码复用要考虑是否给问题排查带来不便

日100万PV的架构如何设计？对于这样的问题，下面简单为大家解答思路：

  • 首先应尽量考虑把网站数据放到CDN中缓存,独立的静态服务器最适合使用CDN (如：img)
  • 要加速的业务数据应该存在独立的域名
  • 业务内容图片、附件、JS、CSS等静态元素，这样的静态网站域名才可以使用CDN。
  • 剩下的访问量规模需要的架构才是我们需要设计考虑的。

架构演进

  • 【原则1】架构演进是为了促进业务发展
  • 【原则2】新技术要带来典型的价值才考虑演进 —— 投入、产出
  • 【原则3】微服务拆分粒度——能不分就不分，除非有非常必要的理由
  • 软件开发没有银弹——《人月神话》
  单体架构 分布式架构
垂直架构		 SOA架构
面向服务的架构		 微服务架构
特点 一个项目 集中部署
模块间 本地调用		 按业务垂直拆分
系统与系统之间的存在数据冗余(如：客户管理)
系统之间的接口多为实现数据同步		 基于分布式架构，它将不同业务功能按服务进行拆分
并通过这些服务之间定义良好 的接口和协议联系起来。
将重复公用的功能抽取为组件		 对服务层进行细粒度的拆分
所拆分的 每个服务只完成某个特定的业务功能
【单一职责】服务层按业务拆分为一个一个的微服务
微服务之间采用RESTful、RPC等轻量级协议传输。
有利于前后端分离
优点 前期开发成本低
开发效率高
运维成本小
容易测试		 子系统功能简单
前期开发成本低
每个子系统可按需伸缩
每个子系统可采用不同技术		 将重复的功能抽取为服务，提高开发效率
提高系统的可重用性、可维护性		 有利于资源重复利用，提高开发效率
服务独立、灵活、按需伸缩
适用于互联网时代，产品迭代周期更短
缺点 对大项目不易开发、扩展、维护
牵一发而动全身
无法按需伸缩		 子系统之间存在数据冗余、功能冗余，耦合性高
按需伸缩粒度不够		 系统与服务的界限模糊
会导致抽取的服务的粒度过大，系统与服务之间耦合性高		 开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成
微服务过多，服务治理成本高，不利于系统维护
适用场景 小项目首选 中型应用
单体遇到瓶颈		 中型应用
分布式架构 臃肿		 大型应用
容量 十万     百万

千万级可考虑多机房，亿级可以考虑用户分区

考虑用户增长速度，最迟在用户量达到下一级别的60%时就应该考虑演进

如何说服老板进行演进

  • 成熟技术——先谈降成本，再提提升技术水平、团队动力，不要本末倒置！
  • 全新技术——竞争对手是否引入新技术，谈客户体验
  • 政策变化——谈大环境、政治意义，如：国产化

动静分离

静态请求 缓存，CDN

动态请求

削峰填谷

负载均衡

中小企业互联网公司网站在并发访问和总访问量不是很大的情况下，建议首选Nginx负载均衡， 理由是Nginx负载均衡配置简单、使用方便、安全稳定、社区活跃，使用的人逐渐增多，成为流行趋势， 另外一个实现负载均衡的类似产品为Haproxy（支持L4和L7负载，同样优秀，但社区不如Nginx活跃）。

如果要考虑Nginx负载均衡的高可用功能，建议首选Keepalived软件， 理由是安装和配置简单，使用方便，安全稳定， 与Keepalived服务类似的高可用软件还有Heartbeat（使用比较复杂，不建议初学者使用）。

如果门户或大型网站的流量巨大，还可在负载均衡器前再加LVS等处理4层请求的负载均衡器，Nginx负载均衡器只负责处理7层HTTP应用层请求的调度，4层的处理效率比7层的效率要高10倍以上，如果流量再大，可以再加上OSPF调度或DNS调度以承受更大的并发访问。

架构选型

  • 快速响应——熟悉什么就用什么
  • 拿来主义——尽量用现成的方案，如：云服务、开源方案
  • 降低成本——上云降低运维和机房成本，机器审核降低人员成本
  • 提升效率——大数据平台提升分析效率，容器提升运维效率，微服务提升开发效率
  • 提升质量——推荐系统提升用户转化率，中台提升多业务开发效率，容器弹性支持业务峰值

安全与监控

跳板机可以使用Shell或者Python开发，也可以使用商业版例如齐治堡垒机等产品。

故障排查

经常查看服务运行日志是个很好的习惯，也是高手的习惯

MySQL

如发现3306端口没起来，请tail-100/application/mysql/data/机器名.err查看日志信息，看是否有报错信息，然后根据相关错误提示进行调试。

I/O 多路复用模型

Linux Freebsd Solaris Windows
epoll kqueue /dev/poll icop

2.项目管理

git规则

迭代节奏

开发流程

开发时间评估

  • 需求调研、确认
  • 技术方案(SQL现行，能用sql刷数的不写代码

    理清依赖关系，拆分上线步骤

建表、初始化、刷历史数据

写SQL确认功能可行性

  • 接口拆分
  • 编码+单元测试
  • 【测试】接口测试、页面测试
  • 验收测试数据准备
  • 文档编辑
  • 联调、bug回归
  • 线上环境准备(数据库更新,ES重建索引)
  • 代码审核(自己review、互审)

3.代码质量

代码规范

Controller && Console

Service

  • 数据读写逻辑分离
  • 多表操作走事务，事务保持简单
  • 多次读考虑使用合并读取(再使用Collect获取数据) 或 缓存(临时缓存、Redis缓存)
  • 多次写考虑使用批量更新
  • 记录日志

Repository

Model

Export

Event && Listener

基类、统一接口

TDD-测试驱动开发

CodeReview-交叉评审

数据格式

Danger

自增ID【包括user_id】不用于业务, 每个表除了自增ID之外需要有业务相关的唯一值

租户ID + 雪花ID/UNIQUE值(如userName、手机号等) 唯一索引

  • 方法定义时明确数据格式
  • 除统计类数据，常量数据 返回 单值类型外
  • 其他数据返回格式默认使用数组格式，方便扩展
  • 接口返回 data 内部必须是数组格式
  • 方法的返回值 避免使用map, 返回多列更方便在调用处组装需要的各种map

刷数据

Danger

铁律：【刷数据之前先备份整个表】

数据库主从

Tip

主从导致受理前端请求的服务器是随机的，导出文件必须实时生成，不能提前存储

异步处理的导入数据，可以拆分成父子表存储数据，下载导出结果时读数据库实时生成文件

锁

  • 普通数据变更加乐观锁
  • 核心数据变更加分布式锁

单据状态变更

  • redis锁提前拦截处理中的单个数据
  • MySQL乐观锁确保操作不被干扰，避免多个人同时操作一个单据(单个操作、批量操作)
  • 预留中间过程(10 20 30作为主流程节点，11 21 22 33这些作为可选中间过程)

唯一索引

  • 某个业务有多个表，应有一个与业务无关的字段作为唯一索引

    兼容业务1:1可能变更为1:N的场景，减少改动

    举例：rules、detail、log,
当V1需求 rules里的 business_A是唯一的，将business_A+tenant_id作为联合唯一索引 获取detail、log数据都没有问题
当V2需求 rules里的 business_A + 场景 才唯一，V1逻辑里基于 business_A 获取聚合数据的逻辑要重新设计