01 . 中小企业到亿级流量架构演进过程
目前中小企业架构设计存在哪些问题?
# 1. 通病: 企业组织管理混乱
# 原因： 没有完善的企业组织架构（分工和责任不明确）
# 2. 部门协同差劲
# 原因: 企业没有规范的管理流程，部门之间沟通机会少，企业文化融合氛围不浓等等造成的.
# 3. 组织效率低
# 原因: 多方协同出现了问题
1 . 战略方向不明确，组织缺乏前瞻性
# 务实,务虚
# 初心: 解决这个社会的问题，解决某个行业的痛点，我希望来做的更好
# 使命,价值观
# 拷克: 业绩和价值观五五开
2 . 部门职责不清晰,重置和空白
3 . 管理层级多，管理角色错位
# 扁平化
# 事业部
# 阿米巴
4 . 企业内部体系不完整，责权不统一
权
责
利
5 . 部门协同差，组织效率低
中小企业IT系统架构面临的问题
# 当业务发生变化，不断的在原有系统上打补丁
# 当业务发展时，系统不断出现瓶颈
# 卡顿，数据库经常锁死
# 用户网站打不开，白屏
# 流量一上来就容易挂
技术团队的现状
# 技术团队人数不超过50人
# 服务器数量: 10-50台
# 宽带: 100M
中小企业从零开始目前项目开发现状:
# 应用系统开发
# 前端开发: Vue.js,bootstrap
# SSM: SpringMVC,SpringBoot,MyBatis
# Tomcat
# 数据库开发:
# Mysql: CRUD
# 测试:
# 开发人员自己测试
# 没有压测
# 不清楚系统的负载边界.
# 线上部署:
# 应用服务器和数据库服务器在同一台服务器上
# Linux环境没装过JDK,Mysql，如何参数配置和调优.
为什么会出现这么多问题？
# 企业没有一个优秀的架构师
怎样才能成为一名优秀的架构师
# 得有实战经验
# 实战的应用场景
历经15次架构演进过程
# 首先:
定义当前企业的架构，目前所处的一个阶段并且绘制出架构图谱
# 定位问题:
根据实际情况绘制新的架构图谱(重构)
在看下面架构演变请先看以下基础概念
基础概念
分布式
系统中的多个模块在不同服务器上部署，即可称为分布式系 统，如Tomcat和数据库分别部署在不同的服务器上，或两个相同功能的Tomcat分别部署在不同服务器上
高可用
系统中部分节点失效时，其他节点能够接替它继续提供服务，则可认为系统具有高可用性。
集群
一个特定领域的软件部署在多台服务器上并作为一个整体提供一类服务，这个整体称为集群。
负载均衡
请求发送到系统时，通过某些方式把请求均匀分发到多个节点上，使系统中每个节点能够均匀的处理请求负载，则可认为系统是负载均衡的
正向代理和反向代理
系统内部要访问外部网络时，统一通过一个代理服务器把请求转发出去，在外部网络看来就是代理服务器发起的访问，此时代理服务器实现的是正向代理；当外部请求进入系统时，代理服务器把该请求转发到系统中的某台服务器上，对外部请求来说，与之交互的只有代理服务器，此时代理服务器实现的是反向代理。简单来说，正向代理是代理服务器代替系统内部来访问外部网络的过程，反向代理是外部请求访问系统时通过代理服务器转发到内部服务器的过程. 可以看我squid和nginx的代理相关文章, 写的不好欢迎留言,我看到会改正
以下架构调整参考来自淘宝
第一次架构: 单体架构
# Tomcat + 数据库部署在同一台服务器上:
# 问题:
# 1. 随着用户增长，tomcat和数据库之间相互竞争服务器资源
# 2. 单机性能不足以支撑业务
# 3. 整个服务器挂掉
第二次架构: Tomcat和数据库分开部署
# Tomcat和数据库分别独占服务器资源，显著提高两者的性能
# 问题
# 1. 用户增长: 读写都在同一个数据库，压力很大，数据库就成了瓶颈
# 2. 第一步: 把应用服务器和数据库进行分表，独立部署，Tomcat和数据库服务器内存扩大
# 数据量小的时候，导出SQL，数据多，数据文件的迁移.
第三次架构: 引入本地缓存和分布式缓存
# Tomcat服务器上或同JVM增加本地缓存
# 在外部增加分布式缓存
# 缓存热数据和静态html页面
# 通过缓存把大多数的请求在读写数据库前拦截掉
# 会应用到那些技术栈尼?
# memcached 作为本地缓存
# Redis作为分布式缓存
# 问题.
# 缓存一致性，缓存穿透/击穿，缓存雪崩
# 热点数据集中生效
# 缓存抗住了大部分用于请求，用户增长，并发的压力就会落到tomcat上，响应很慢
第四次架构: 引入反向代理实现负载均衡
# 多台服务器上分别部署tomcat,使用Nging把请求分发到每一个tomcat中
# 假设:
# Tomcat最多支持100并发
# Nginx请求分发500个Tomcat，就能抗住50000个并发
# 问题:
# Session共享
# 文件上传下载问题
第五次架构: 数据库读写分离
# 读库
# 写库
# MyCat等等数据库中间件
# 问题:
# 数据同步，数据一致性问题
# 业务增长，不同业务之间访问差距较大，相互竞争数据库资源，影响性能
第六次架构: 数据库按业务分库
# 问题
# 用户增长: 单机的写库会逐渐达到性能瓶颈
第七次架构: 将大表分成小表
# 问题:
# 数据库和Tomcat能够水平扩展，Nginx就会成为系统的瓶颈
第八次架构: 使用LVS或者F5使用多个Nginx负载均衡
# 问题:
# LVS单机
第九次架构: 通过DNS轮训实现机房间的负载均衡
# 通过DNS服务器轮训或者其他策略
# 千万级别到亿级别，通过机房来解决
第十次架构: 引入NoSQL数据库和搜索引擎
# 对于全文检索，可变数据结构，数据库天生不适用
# 海量文件存储: HDFS
# Key Value类型的数据: HBase 和Redis
# 全文检索: ElasticSearch
第十一次架构: 把大应用拆分为小应用
# 按照业务板块来划分应用代码
# 单个应用职责很清晰，相互之间做到独立升级迭代
# 应用之间会涉及公共配置
# 分布式配置中心 ZooKeeper来解决
第十二次架构: 复用的功能抽离成微服务
第十三次架构: 引入企业服务总线屏蔽服务接口访问的差异
第十四次架构: 引入容器化技术实现环境隔离和动态服务管理
# 目前最流行技术是Docker
# 容器管理: kubernetes
# 双11来之前:
在现有的机器集群上划分出服务器来启动Docker容器，增强服务的性能
# 双11之后:
活动结束后: 就可以关闭容器，对机器上的其他服务不会造成任何影响
第十五次架构: 以云平台承载系统
# 所有系统都部署在公有云上:
# 2019年双十一天猫2684亿，阿里巴巴所有核心系统全部上云.
# 系统可部署到公有云上,利用公有云的海量机器资源,解决动态硬件资源的问题,在大促的时间段里,在云平台中临时
# 申请更多的资源，结合Docker和k8s来快速部署服务,在大促结束后释放资源，真正做到按需付费,资源利用率大大提高,
# 同时降低了运维成本.
# 所谓的云平台，就是把海量机器资源，通过统一的资源管理，抽象成一个资源整体，在之上可按需动态申请硬件资源(
# 如CPU，内存，网络等),并且之上提供通用的操作系统，提供常用的技术组件(比如Hadoop技术栈，MPP数据库等)供用户
# 使用,甚至提供开发好的应用，用户不需要关心应用内部使用了什么技术，就能解决需求(视屏转码服务，邮件服务，
# 个人博客等)，在云平台中会涉及以下几个概念.
# IaaS: 基础设施即服务,对应上面所说的机器资源统一为资源整体，可动态申请硬件资源的层面:
# PaaS: 平台即服务,对应上面所说提供常用的技术组件方便系统开发和维护,MaxComputer,Fink-Bink,Hadoop技术组件
# SaaS: 软件即服务,对应上面所说的提供开发好的应用或服务,按功能和性能要求付费,比如:
#（行业解决方案视频转码服务，邮件服务，个人博客等）
# 于是各种云平台应运而生:
# 阿里云
# 腾讯云
# 七牛云
# 青云
架构设计
架构的调整是否必须按照上述进行架构?
以上所说的架构演变顺序只是针对某个侧面进行单独的改进，在实际场景中，可能同一时间会有几个问题需要解决，或者可能先达到瓶颈的是另外的方面，这时候就应该按照实际问题实际解决。如在政府类的并发量可能不大，但业务可能很丰富的场景，高并发就不是重点解决的问题，此时优先需要的可能会是丰富需求的解决方案。
对于将要实施的系统，架构应该设计到什么程度?
对于单次实施并且性能指标明确的系统，架构设计到能够支持系统的性能指标要求就足够了，但要留有扩展架构的接口以便不备之需。对于不断发展的系统，如电商平台，应设计到能满足下一阶段用户量和性能指标要求的程度，并根据业务的增长不断的迭代升级架构，以支持更高的并发和更丰富的业务
架构设计原则
# `N+1设计`
# 系统中的每个组件都应做到没有单点故障；（HA）
# 回滚设计: 确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
# 禁用设计: 应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
# 监控设计: 在设计阶段就要考虑监控的手段；
# 多活数据中心设计: 若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
# 采用成熟的技术: 刚开发的或开源的技术往往存在很多隐藏的bug，出了问题没有商业支持可能会是一个灾难；
# 资源隔离设计: 应避免单一业务占用全部资源；
# 架构应能水平扩展。系统只有做到能水平扩展，才能有效避免瓶颈问题；
# 非核心则购买。非核心功能若需要占用大量的研发资源才能解决，则考虑购买成熟的产品；
# 使用商用硬件。商用硬件能有效降低硬件故障的机率；
# 快速迭代。系统应该快速开发小功能模块，尽快上线进行验证，早日发现问题大大降低系统交付的风险；
# 无状态设计。服务接口应该做成无状态的，当前接口的访问不依赖于接口上次访问的状态。
