2020 小结

待我称王封你为后i 2022-10-25 00:52 189阅读 0赞

# 2020 小结 #

> 2020 年写博客非常少，一方面是毕业进入工作，进入了人们所说的国内顶尖互联网大厂，发现自身有非常多的进步空间，没那么多充足的时间专门用来写博客，而是积累经验并应用于实践。

## 初出茅庐 ##

毕业后，身份从学生狗换成了打工人，工作和学校中学的内容差异还是非常大的，但这并不妨碍，因为在我看来，进入该行的大都是有自行、主动学习过项目的开发的，只要你在学习中真正自己做过系统，会发现 just so so，你做的事情，就是你学过的，只不过是实现方式可能有差异罢了。

## 初窥门径 ##

很快，你会熟悉自身部门的业务、项目结构、有兴趣还会了解系统的整体架构，为什么这么设计，有没有更好的方案，为什么没有用，结合所在业务场景，成本（开发、人员投入、部门员工能力、维护、测试），会得出这些更好的方式有不同的优先级，并不是所有好的东西都会去做，哪怕它性能再好，技术再先进；当然也会得出来有的东西值得你去做，去推广。

若你对技术有兴趣，有思考，你可能发现二方库/ jar包 的实现有较大问题，使用不方便，如不能灵活扩展、后人难维护，这很正常，因为它可能是很早之前的代码，也可能它能基本满足使用，还没有人去优化他。

基于自己的理解，也尝试参与过框架的开发，自己安排收集这块需求，该如何设计，落地，检查反馈、发布、迭代的过程。

切切实实体会到，合理的抽象，抽出框架能够节省开发成本，减少新员工上手难度，可以专注于业务，而非过多关注实现细节。

## 略有小成 ##

做某件事有正向反馈，自然就会激发人们对这件事更大的兴趣。不仅仅是自己部门，其他部门甚至全公司大部分的业务线，几百个项目中使用自己设计的部分，激起了我对这部分的兴趣，不仅仅是将知识理解，如分布式、高并发、高可用、可灰度、可监控尝试落地，如改造原有的单体项目支持自身集群、支持中间件集群，考虑更优雅的幂等、高可用。

发现这里有很多很多学问，如高并发，从 java 编码 到 jvm 的设计，再到它的 c++ 实现（jvm源码），可以看到他是如何与系统交互的，结合自己对操作系统的知识储备，进一步学习硬件层（嵌入式的系统）的接口设计，提供了怎样的能力，学习这些非常有趣，我也借着某个点来实践过。

分布式系统中有这么一种常见常见，就是分布式插入数据库时，需要生成全局不重复的标识，最好是趋势递增的索引标识。简单来讲，java 的UUID就能实现，但他不是递增的，生成性能高，但对数据库来说作为索引，效率较差。

后了解到滴滴、美团、腾讯、百度…很多大厂都有自己的开源实现，其中美团给出了 snowflake 的java实现，也是网上最广为流传的版本，个人看到其 synchroned 略有嫌弃。性能最高的就属百度的 uid-generator，号称每秒生成 **700w** 个不重复的全局趋势递增 long 类型 id，并解决`类snowflake` 的时钟回拨、序列超发等问题，看了一下它的实现，确实从 java 编码，到 jvm 调度，再到操作系统，甚至到 CPU 的设计，都是针对性优化，颇具匠心。

但在我看来，我也有思路，我也想实现，和他比拼以下，能不能达到它的水平，自己距离高并发究竟差多少，经几番研究设计后，终于想办法巧妙地把锁去掉了，并解决 snowflake 中的弊端，仅仅默认参数，性能就达到了百度算法的近 60 倍！  
[我把 Snowflakes 的算法性能提升了万倍！！][Snowflakes]

说实在的，当今世界的 99.99 % 的业务场景中不需要这么高的性能，或有自己的业务考量和取舍，因此我把本次的高并发作为一个兴趣活动来看了。

## 目标 ##

想自己单独设计实现一个较为**完善的分布式、高可用系统**，因为完成这个目标可以帮助我更好的理解整个系统的设计与落地，除了开发眼中看到的点，我相信还有更多的点需要注意，开发看到的只是完成整个系统需要做的冰山一角。

首先，对于单人来说，这个目标成本十分巨大，为了更快的完成它，需要将重复的一些事情抽离，同时，我是为了学习而做的，不是为了做而做的，而且要极大的压缩维护成本，因此需要合理的设计系统的分层，以便于单人都能管理与维护。

鉴于此，我把系统拆分为

*  IaaS 层，基础设施层，如 CPU、内存、网络等，这块不涉及软件开发，因此我选择依赖云厂商，为了与云厂商解耦合，我打算使用容器化技术，如 `Docker`。
 *  iPaaS 层 平台基础设施，如数据库、缓存系统、监控系统、MQ消息系统、搜索引擎、注册中心、告警系统等，这些开发成本高，且业界有较为优秀的实现，每套系统我会挑选较好的，为了便于部署、维护、调优，我把他们打包成容器镜像，见[shoulder-ipaas][]
 *  PaaS 层，平台层，提供身份认证、系统参数管配、权限校验、存储中心、网关、推送中心、营销中心、后台管理等等，这些是整个系统的基石，放在 [shoulder-platform][]
 *  规范层 平台需要要为系统各个上层服务提供能力，工作量大，为了提高效率，需要将重复的部分抽出，无论是开发、还是模块分层、代码管理、发布运行，错误排查，因此可以通过统一各个系统的设计，制定一系列规范，减少开发维护成本，放在 [shoulder-spec][]
 *  框架层 无论是平台层、还是上层服务，既然都需要遵循一些规范，中间件，这些绝大部分是重复的工作，且工作量还不少，为了复用和便于维护，抽离框架层于 [shoulder-framework][]
 *  当然，如果系统中存在异构系统，java框架提供的能力就很难在其他开发语言中复用（如 js、php、go等），需要尽量将框架层能力下沉，最好是下沉至基础设施层，或者中间，如放到基础镜像中，这样，在开发者角度看来，框架提供的能力就沉淀至基础设施蹭了， 也就是云原生，我认为他是未来，十分看好，但云原生现在还是探索阶段，哪怕是顶尖的互联网大厂中，也是概念萌芽；且本系统不涉及异构，故采用框架，暂不探索云原生。
 *  框架验证/demo层 框架有了，为了隔离实现细节，通过数个 demo 工程，来验证、表达框架（包含 jar、插件、IDE插件）提供的能力
 *  共性业务层，基于以上的通用能力，这部分是针对于某个行业的，这里提供基础能力外，提供租户隔离，业务核心。
 *  行业 SaaS，基于上层的能力，提供专项能力，并支持租户隔离。

最终实践一项高可用、可扩展的完整系统。

[Snowflakes]: https://blog.csdn.net/qq_35425070/article/details/109234491
[shoulder-ipaas]: https://gitee.com/ChinaLym/shoulder-ipaas
[shoulder-platform]: https://gitee.com/ChinaLym/shoulder-platform
[shoulder-spec]: https://spec.itlym.cn/
[shoulder-framework]: https://gitee.com/ChinaLym/shoulder-framework