课程简介
本序列课程主要和大家一起探讨在随需应变，快速响应的互联网大背景下，面对用户多分布广泛、高并发大流量、安全环境恶劣易受网络攻击等特殊环境下,如何在使用廉价服务器的情况下,构建出一个即可满足业务的高性能需求,又能达到5个9、6个9的高可用性,还能解决快速迭代需求，稳定高效的互联网系统中台架构及其设计实践方案。
本课程由技术栈的选型开始引入主题，结合相应的业务，并且考虑相关配合团队的水平、人员组成情况等序列因素，主要从选型比较、解决重点/难点问题、实现策略、实施方案的优势优点、成本对比、实施过程的经验教训、实施案例及其感想、后期的改进与维护升级等具体的方面进行一个完整的陈述,重点讲述组件之间在分布式的情况下,如何通过各司其职的配合,从而实现高性能,高可用,高伸缩。
具体技术方面，本课程主要以自我实现中台为主,使用开源为辅的策略，包括但不局限于：java的IOC、ORM，Restful等框架、JOB调度系统、ID生成器、HTTP服务器、DFS分布式文件系统、缓存与存储系统、分布式协调器、配置服务、通讯协议、日志监控等。
最后我们将讨论这些系统是如何与业务有机的结合案例与当时如此实施的指导思想，并且大家一起探讨实施过程中如何通过项目实现“快速响应”的控制,从而达到另外一种层面(对于项目及源码的控制层面)的高可用性,这一点往往是被严重忽略的。
目标收益
1. 掌握如何从头到尾设计一个稳定、快速、能满足业务需要的系统架构方案
2. 掌握如何从无到有的实现一个看似不可能自己实现的中台组件
3. 掌握如何有机的选择与使用开源或者自主开发的中台组件，将其有机的整合在一起，从而让业务在分布式的情况下达到高性能,高可用,高伸缩.
4. 掌握如何控制系统边界、如何控制因需求追加而导致的软件复杂度,如何更好的让各组件各司其职.
5. 掌握如果控制整个庞大的系统的一切，包括：团队、“开发人员”、“需求人员”等等
6. 了解一般常用开源软件的优缺点，面对业务如何舍取，以及如何二次开发或者新开发一个替换它。
7. 了解linux下高性能中台组件的开发方法。
培训对象
CTO、高级工程师、架构师、中间件开发人员
对系统架构感兴趣的开发人员
课程大纲
|
Albianj技术栈 数据聚合与日志统计 |
选型比较：1. spring 2. mycat 3. sharing jdbc 4. 各种公司（51）之类的开发的技术栈 突出解决的问题：大部分的phper转java 业务更改频繁且时间要求高 要求down机时间短，有指标 指导思想：控制项目，控制时间，控制复杂度。最关键是控制人 高性能高可用扩展海量数据： 1. 自带分布式事务解决方案 2. Bundle机制解决分离同进程不同业务 3. 无限平行扩展，扩容自主化 4. 自带分库分表（数据路由）解决海量数据问题 5. 自带加密组件，解决安全问题 6. 自带漏斗，令牌环等算法解决防刷，重复提交等问题 7. 自带数据库调优模板，解决批量数据提交问题 |
| scher系统 |
选型比较：quartz corn4j 突出解决的问题：job调度 job之间不能相互影响，并且可以方便的kill有问题的job v1版本的quartz为啥有问题 指导思想：开发人员最简单，易使用 复杂配置全部scher自带 进程单位分开，互不干涉 高性能高可用扩展海量数据：1. 分布式模式解决了job的高扩展与高性能 2. arbiter解决了job的高可用问题 3. 自研分配算法解决了job的负载均衡问题 4. chunk机制解决了job的数量与业务交叉问题 |
| 精卫系统 |
选型比较：当时没有参照，从scher引申而来 突出解决的问题：无法与scher在一起，容易造成相互影响 job需要和scher兼容 指导思想：让他单身吧，不要被scher影响 高性能高可用获取海量资源： 1. 分布式模式解决了job的高扩展与高性能 2. arbiter解决了job的高可用问题 3. 自研分配算法解决了job的负载均衡问题 4. chunk机制解决了job的数量与业务交叉问题 |
| 配置服务 |
选型比较：zookeeper 突出解决的问题：配置文件上线麻烦 秒更或者短时间（3s）之内 指导思想：防止泄露，不停机更新配置 高性能高可用高扩展海量数据： 1. dispatcher解决了高可用高扩展问题 2. 全局pull模式解决服务器高性能问题 3. 版本号解决了高可用问题 4. sharingmemory解决了业务机高可用问题 |
| DFS分布式文件系统 |
选型比较：1. mfs 2. fastdfs 3. TFS 4. ceph 突出解决的问题：频繁的更改 全部是小文件，99.9999是3-5k 数量超级大 指导思想：解决特殊业务（小文件太多）的问题 比如无人干预运行 高性能高可用获取海量数据： 1. event nio编程解决高性能问题 2. 角色设计解决高扩展高可用性问题 3. 无锁编程解决单台服务器负债问题 4. 合并随机写解决性能问题 5. chunkfile机制解决磁盘碎片与存储海量数据问题 6. 软负债解决高可用性 7. GISSOP算法解决同步数据完整性问题 |
| http服务 |
选型比较：没有现成的，唯一的可能就是写ngx或者类似于这样的插件 突出解决的问题：1.图片，音频，视频 2. 需要链接我们的DFS 指导思想：这个纯粹是好玩，并且想玩一下JNI，兴趣孜然 高性能高可用扩展海量数据： 1. C网络编程解决高性能问题 2. JNI解决JAVA与C之间的通讯问题 3. JAVA解决业务的多变问题 |
| id生成器 |
选型比较：twrrite snowflow UUID 突出解决的问题：分库分表需要使用 主键与排序 人肉眼可识别 指导思想：易排错，内部人员能第一时间看懂 高性能高可用获取海量数据：1. ID服务器横向扩展 2. 多主模式解决性能与高可用问题 3. 事件编程解决10K，100K的链接高并发问题 4. ID实现分库分表路由功能 |
| lest KV存储 |
选型比较：redis 突出解决的问题：有持久化 qps单机可以到3w以上 支持版本化与同步 指导思想：持久化，无人干预，可以接受相比redis有10-20%左右的性能差距 高性能高可用获取海量数据：1. 多主设计解决了高可用、高性能问题 2. 路径算法解决了高性能问题 3. voctorlocker算法解决版本问题 4.list和map的存储机制解决了内存数据平行化存储问题 5.bsearch算法解决了获取数据的性能问题 |
| lax分布式协调器 |
选型比较：zookeeper 突出解决的问题：机房网络不稳定，选举就是噩梦 性能不高，扩展不方便 指导思想：zookeeper太庞大，太不好用，低网络要求太高， 没有主从，没有主从，没有主从 高性能高可用获取海量数据：1. 无主无投票机制解决了网络环境下的高可用问题 2. 随机算法解决了分布式下的碰撞问题 3. 多写机制解决了高扩展问题 |
| 通讯协议 |
选型比较：messagepack bufferprotocol之类的 突出解决的问题：不喜欢编译型 有一个支持任何语言的查找模型 指导思想：对开发人员无感知 高性能高可用获取海量数据：1. 无编译解决易用性问题 2. 无数量限制解决了传输数据量问题 3. 二进制协议解决了高性能问题 |
| 总结陈词 | 系统设计总结，讨论人、团队、业务、架构、系统、bug之间的关系 |
|
Albianj技术栈 数据聚合与日志统计 选型比较：1. spring 2. mycat 3. sharing jdbc 4. 各种公司（51）之类的开发的技术栈 突出解决的问题：大部分的phper转java 业务更改频繁且时间要求高 要求down机时间短，有指标 指导思想：控制项目，控制时间，控制复杂度。最关键是控制人 高性能高可用扩展海量数据： 1. 自带分布式事务解决方案 2. Bundle机制解决分离同进程不同业务 3. 无限平行扩展，扩容自主化 4. 自带分库分表（数据路由）解决海量数据问题 5. 自带加密组件，解决安全问题 6. 自带漏斗，令牌环等算法解决防刷，重复提交等问题 7. 自带数据库调优模板，解决批量数据提交问题 |
|
scher系统 选型比较：quartz corn4j 突出解决的问题：job调度 job之间不能相互影响，并且可以方便的kill有问题的job v1版本的quartz为啥有问题 指导思想：开发人员最简单，易使用 复杂配置全部scher自带 进程单位分开，互不干涉 高性能高可用扩展海量数据：1. 分布式模式解决了job的高扩展与高性能 2. arbiter解决了job的高可用问题 3. 自研分配算法解决了job的负载均衡问题 4. chunk机制解决了job的数量与业务交叉问题 |
|
精卫系统 选型比较：当时没有参照，从scher引申而来 突出解决的问题：无法与scher在一起，容易造成相互影响 job需要和scher兼容 指导思想：让他单身吧，不要被scher影响 高性能高可用获取海量资源： 1. 分布式模式解决了job的高扩展与高性能 2. arbiter解决了job的高可用问题 3. 自研分配算法解决了job的负载均衡问题 4. chunk机制解决了job的数量与业务交叉问题 |
|
配置服务 选型比较：zookeeper 突出解决的问题：配置文件上线麻烦 秒更或者短时间（3s）之内 指导思想：防止泄露，不停机更新配置 高性能高可用高扩展海量数据： 1. dispatcher解决了高可用高扩展问题 2. 全局pull模式解决服务器高性能问题 3. 版本号解决了高可用问题 4. sharingmemory解决了业务机高可用问题 |
|
DFS分布式文件系统 选型比较：1. mfs 2. fastdfs 3. TFS 4. ceph 突出解决的问题：频繁的更改 全部是小文件，99.9999是3-5k 数量超级大 指导思想：解决特殊业务（小文件太多）的问题 比如无人干预运行 高性能高可用获取海量数据： 1. event nio编程解决高性能问题 2. 角色设计解决高扩展高可用性问题 3. 无锁编程解决单台服务器负债问题 4. 合并随机写解决性能问题 5. chunkfile机制解决磁盘碎片与存储海量数据问题 6. 软负债解决高可用性 7. GISSOP算法解决同步数据完整性问题 |
|
http服务 选型比较：没有现成的，唯一的可能就是写ngx或者类似于这样的插件 突出解决的问题：1.图片，音频，视频 2. 需要链接我们的DFS 指导思想：这个纯粹是好玩，并且想玩一下JNI，兴趣孜然 高性能高可用扩展海量数据： 1. C网络编程解决高性能问题 2. JNI解决JAVA与C之间的通讯问题 3. JAVA解决业务的多变问题 |
|
id生成器 选型比较：twrrite snowflow UUID 突出解决的问题：分库分表需要使用 主键与排序 人肉眼可识别 指导思想：易排错，内部人员能第一时间看懂 高性能高可用获取海量数据：1. ID服务器横向扩展 2. 多主模式解决性能与高可用问题 3. 事件编程解决10K，100K的链接高并发问题 4. ID实现分库分表路由功能 |
|
lest KV存储 选型比较：redis 突出解决的问题：有持久化 qps单机可以到3w以上 支持版本化与同步 指导思想：持久化，无人干预，可以接受相比redis有10-20%左右的性能差距 高性能高可用获取海量数据：1. 多主设计解决了高可用、高性能问题 2. 路径算法解决了高性能问题 3. voctorlocker算法解决版本问题 4.list和map的存储机制解决了内存数据平行化存储问题 5.bsearch算法解决了获取数据的性能问题 |
|
lax分布式协调器 选型比较：zookeeper 突出解决的问题：机房网络不稳定，选举就是噩梦 性能不高，扩展不方便 指导思想：zookeeper太庞大，太不好用，低网络要求太高， 没有主从，没有主从，没有主从 高性能高可用获取海量数据：1. 无主无投票机制解决了网络环境下的高可用问题 2. 随机算法解决了分布式下的碰撞问题 3. 多写机制解决了高扩展问题 |
|
通讯协议 选型比较：messagepack bufferprotocol之类的 突出解决的问题：不喜欢编译型 有一个支持任何语言的查找模型 指导思想：对开发人员无感知 高性能高可用获取海量数据：1. 无编译解决易用性问题 2. 无数量限制解决了传输数据量问题 3. 二进制协议解决了高性能问题 |
|
总结陈词 系统设计总结，讨论人、团队、业务、架构、系统、bug之间的关系 |
近期公开课推荐
