留念
应几位朋友之邀，放一下图，也给自己留个纪念，数年后回想起，曾经我花了半年迭代出这么一个设计，哈哈，不知道到时候是什么感觉，会不会像我现在看一年前的设计图一样感觉傻，还是为进步而开心。
然后，本文的所有知识点都在我的其他博客中可以找到，我不会放链接，信我的，在我的博客主页搜索；
当前架构
土是土了点，应该能叫“架构图”了吧。
稍微解释一下：
网络层：muduo + pb + tcp/ip + api安全接口设计。
选择 muduo 是因为它是我目前技术栈里最高可用的网络库了。注：我的毕设是一个高可用系统。
选择 pb，我试过，同样一个包，pb 压缩后所占空间直接是 json 的 1/5 左右，甚至对于 0 值，pb 是直接省略的，这也可以拿来做文章的。就算选用了 pb，在字段上我依旧极致省略，首先就统统都是 int，字符串的话就映射成 int。其次 int 一定要尽量拼凑到 8 位数才发，如果超出 8 位，那就用 long。再怎么样，一个字段总比四个字段要省。
选择 tcp/ip，我就不说话了吧。
api 安全接口设计，自行了解。
业务层：这里的业务都被我抹掉了，不过有几点要注意的，通用的。
1、分布式系统要注意分布式锁。
2、对于登录业务要注意二次登录。
3、对于注册业务，采用自增 id 的时候要掂量一下，分布式环境的自增 id 没那么简单。可以在我的博客主页搜索一下“自增 id”。
3、对于 MySQL 可以考虑存储过程，只要不是太复杂，因为存储过程的调试是真的要呕血三升的，我调过。
4、业务和数据库之间一定要做熔断。
5、最好能有 IP 限流模块，这个模块开发的晚，就没在图中展示了。因为我自己系统的特殊性，我就设定，不论你是谁，一秒都只能访问一次，因为我默认你需要阅读一下我返回的内容。那会不会误杀？不可能的，我告诉你，绝对不可能，只要是从我手上出去的客户端，那都是要做防抖的。
其他的暂时还没想到，想到我也不再补了。
持久层：持久层选用 MySQL + Redis。这里要注意：
1、MySQL 有条件的话最好单独部署到别的机子上，没必要，那个网络 I/O 的开销，跟MySQL 的磁盘 I/O 比起来那真不算什么了。
2、有能力一定要做存储过程，前提是要做好调试存储过程的心理准备。
3、Redis 有条件的话最好跟业务层放在一台机子上，Redis是什么？吹破天了它也是个缓存，缓存你不跟主机放一起你要去自立门户吗？然后多走那一圈 I/O？要知道，后端开发很大的一个瓶颈就在于网络I/O，木有带宽呀！！！
4、数据字典。数据字典非常重要，在项目分析阶段一定要有明确的数据字典，而且一定要做单例模式。可以改，但是不能没有，也不能多实例。不然到后期就知道什么叫痛苦了，到时候模棱两可的数据越改越迷糊了。
5、很重要的一点：基准测试。在架构设计之前就要做好的事情。MySQL 可以使用专门的基准测试工具 sysbench，redis 更简单了，人家有自带的。
HA：根据基准测试的结果来设定 HA。不要到时候你的环境只能 hold 住一台 MySQL，你来个主从复制哈，然后跑过来说为什么我的 MySQL 查询这么缓慢，屁话，既要马儿跑，又要马儿不吃草…
性能监控：promethues（存储数据） + NodeExporter（采集数据） + G什么的（数据可视化）
对于图中两个框架，我的博客里也都有。
RPC：远程接口调用。
ORM：对象关系映射。
ORM 比较简单，RPC 可能不是那么好理解。其实图中 RPC 的位置在上一个版本我写的是：命令 + 门面。这两个设计模式我已经删了，当时觉得过于简单，这里我补一下：
命令模式：在业务层存放一个哈希表，键值对形式为 <业务id：业务函数指针>，通过函数调用 get_handle，传入业务id，执行函数指针。
门面模式：整个业务层只对外开放这么一个函数调用 get_handle。
有这两个框架，我可以将我的系统层层解耦，相互之间谁也不要认识谁，我大权在握哈哈。
当前部署
只有这么一个架构图是不够看的，因为你不知道怎么部署。我有一部分代码是在部署图上体现的。
简单解释一下：
可以看到，整个系统都是部署在 docker 上的，做了状态剥离。
状态剥离：将 各种 IP、Port 等配置项移出，填写在 Deployment.json 文件中，此后不管你想把哪个组件挪到哪台机子上，那随便你。
平滑升级：将状态进行剥离之后，那想做平滑升级就很简单了，做一个观察者模式，监控 deployment.json 中 version 的变化，只要 version 变化了，就重新读取配置项。至于新旧组件的交替，那至少得等新的上位了，再把旧的关了嘛。所以这里需要考虑一下你的资源是否充足。
平滑迁移：那我还能说什么呢，状态你都剥离了，我又全在 docker 上，你直接一锅端了呗。
下一版架构图
结束的是毕设，不是我的项目。
简单讲一下变更：
1、业务层拆分微服务，核心业务单独划分，零碎业务凑到一起办了。后面的业务都需要走登录这一块，也想过将登录业务直接作为伴生业务划到网络层的 pod 里面去，但是想了想万一登录业务崩了，连带整个网络层一起崩了。所以：做好熔断、
2、既然业务都拆了，说明流量大了。那 Redis 也拆了吧，用来做锁的单独一块儿，用来承载数据库热点数据的单独一块儿。
3、MySQL 暂时不拆，但是要有能分库分表的能力。
下一版部署图
为什么叫下一版，而不是这一版，其实架构图上也看不出来嘛，因为理论上是实现的了的。
看了部署图，就知道为什么叫 “下一版” 了。
你猜我是哪里不行哈哈。最底下那两块儿，目前还没部署成功…
如果有学弟学妹想做一下以后方便写在自己的简历上，一定要私信我。呈现在这里的就是这么几张图，但是你不知道的是它们每张图，背后都有十几张图的迭代，项目都是从最简单的开始做起，越滚越大越滚越大，一上来就高屋建瓴的，咱不是那天才哈…
