七年之痒-小公司的架构设计感想

七年架构感想

弹指一挥间，自己竟然在开发岗位上坚守了七年之久，从之前的懵懂小白，到现在的油腻甩锅大叔。从之前在小型创业公司全栈开发工程师，到现在平安某电子商务公司的高级后端工程师。大大小小的工程见到了很多，繁繁锁锁的项目也参与过不少。参与过paas云平台的设计开发，参与过区块链为基础的三方协议云签署平台，还有幸进入过携程的邮轮项目组，在里面做过领队项目，出入境模块。做的不开心就进入了一家面向c端的游戏社区公司，搭建整体的项目系统。受疫情影响最后选择了一家有平安背景的电子商务公司，想着好好度过疫情这几年，毕竟树大好乘凉。

基本自己在小公司是直接参与项目的架构设计的，但是在大公司只负责开发，项目的架构本身已经固定好的，同时也有技术中心的同事，和中间件部门的公司辅助，所以在架构方面直接参与的不多，但是在需求分析方面和敏捷管理方面倒是学到了不少。

先说一下在创业公司的架构设计经验吧。
基本背景：
因为是初创公司，项目也是很新的，没有任何的历史负担，所以可以随心所欲的探讨各种技术选型，框架选型，中间件选型。但是都有基本的原则

• 考虑自身的研发力量，尽量使用开源的轮子，切勿自造轮子，浪费人力物力在非业务中。活下来是第一要义。
• 考虑自身的技术方向，尽量与自身擅长的科技树靠拢，切勿选择一个自身不熟悉的架构组件，防止出现浪费时间学习新的知识。
• 选择技术框架或者开源组件时，关注现在主流和热度较高使用的组件，因为有开源社区的力量在帮助我们解决问题，可以解决很多问题。

综上几点所述，我在ceying公司和mingbo公司做项目时采用的是Spring cloud的技术栈，而不是选择dubbo作为远程服务调用框架。因为Spring cloud在开源社区热度高，有一整套的相关组件可以使用，例如zuul或者gateway网关组件，fegin服务调用框架，hystrix服务熔断组件，zikpin链路追踪组件，nacos或者eureka服务注册组件。这些都是Spring cloud全家桶中带有的组件，基本上做到了开箱即用，然后在对项目惊醒领域模型划分，尽可能的拆解服务，这样就可以做到后续的变更，所影响的面会比较少。

远程服务调用框架选型结束，至于选择其他中间件组件时就要依赖自己的真实的业务场景。我们的初创公司是一个面向c端的游戏社区公司，有大量的活动用户，和巨量的潜在用户。本公司项目主要是负责提供游戏爱好者在自己平台下载玩游戏，并且可以找到自己归属的游戏社区发帖咨询。并有一个的积分商城的模块。

在使用关系型数据库方面选定的是mysql，这个无可厚非，对如oracle，mysql开源且免费，并且可以自行搭建集群架构，实在不行还可以借助阿里云腾讯云等云平台去帮助自己实现数据库方面的搭建运维。就算是在大型公司携程或者平安内部也是积极向mysql数据库靠拢。携程公司内部也是有oracle数据库的项目，但是2018年后所有的新项目都是以mysql数据库作为底层数据库，平安某电子商务公司内部也是积极展开去o的行动，与2022年陆陆续续开展去除oracle，拥抱mysql行动。

在缓存方面的技术选型，有很多，jvm级别的缓存有ehcache,guava cache或者自己缓存到map中数据都可以，中间件级别的缓存目前都是采用redis作为缓存中间件。这个可以根据自身的项目情况具体处理，如果是本身用户并不多，服务数据并不多，可以简单采用jvm级别的缓存来处理数据。很多小型创业公司在做技术选型时，喜欢一开始就大搞特搞，项目一开始就讲所有的能引入的组件全部给它引入，但是实际上是不需要的，当你引入这个组件时你需要了解引入这个组件给你的项目带来多大的价值，一切都是以价值来衡量他的意义。
但是根据我们公司的自身的需要，用户众多，数据量大，查询耗时长，所以直接采用的redis缓存的方式。

因为拆解成了微服务化，所以就会产生一个问题，跨服务之间的事务是如何保证，在网上众多的分布式事务解决方案中，例如tcc解决方案，二阶段提交解决方案，和消息中间件最终一致性方案。采用了消息中间件这个方案。在选择消息中间件中，在小公司中选择了rabbitmq这个组件。
至于为什么选择了它，稍后会详细说明。

我的游戏至于其他中间件，我们还采用过了elasticsearch搜索引擎。首先要从需求设计上理解为什么需要它，愿需求是希望能在搜索列表中去查询关键字关联度多的数据，并根据关联度大小进行倒叙排列，例如我搜索 我的游戏，会在关联数据中查询我的游戏，我的，游戏，这些关键词，然后根据关联词有多少，排序展示。这个因为mysql这种关系型数据库无法做到这种关联度的查询，所以只能使用现在的搜索引擎。
上面我们知道需求设计上需要用到搜索引擎。但是目前主流的搜索引擎有二种，一种是solr搜索引擎，一种是elasticsearch搜索引擎。根据比较发现elasticsearch搜索引擎功能更加强大，索引采用了它。

solr	elasticsearch
建立索引时solr是阻塞的	es是异步实时
动态添加数据时，solr检索效率变得低下	es没有任何影响
solr更适合那些存量的数据	es适合那些实时的动态数据
solr适合那些量级不大的场景	es天生就是为了分布式使用的，支持的PB级别的数据
solr支持多种数据结构json xml	es只支持json，这个对我们没有影响，因为我们现在都是json

调度系统，因为有些任务时需要定时去处理的，比如我们有个需求任务是热门游戏列表。

这样算下来，我在这个初创公司所做的技术选型都是Spring cloud ， Spring boot ，gateway (网关组件)，fegin（远程调用组件） , hystrix（服务熔断组件）, zikpin（链路监控组件）,eureka作为服务注册组件，后期使用了nacos作为服务注册组件和远程配置组件。
然后选用了mysql作为关系型数据库，redis作为缓存数据库，微服务之间采用了rebbitmq消息中间件，来做最终一致性方案。因为上面所说的需求设计，引入了elasticsearch搜索引擎。后面添加了elk来试试检索日志文件，达到在线实时检查日志数据，再也不用去服务器去检查日志数据了。

选择这些技术框架既有小公司的特性也有自身的特性，也有其业务的特殊性。实践下来撑住日活10万qps的访问量，但是高峰时期还是无法支持数据的访问量，在数据库方面需要进一步升级技术框架。