这是我参与「第五届青训营 」伴学笔记创作活动的第 16 天
昨天我写了本次大项目的技术选型，那这篇文章我就来写写这次因为时间原因没有来得及使用的技术，以及感想
微服务架构
我们组的项目使用的是非常原始的单体架构，使用了MVC架构，不过很多组使用的是微服务架构，其中这一组的文章思路很清晰，值得我去学习
他们的架构总共经过了三次迭代：
-
第一次：MVC单体架构，分业务模块
- 缺点：无法扩展，可靠性低，敏捷性开发和部署实现困难
-
第二次：进行简单的服务拆分
- 每一个服务采用不同的端口，不一样的进程
- 对外部提供的服务通过http的方式暴露出去
- 内部服务间的调用不再是通过文件路由引用，而是通过GRPC协议暴露出去
- 缺点：对外暴露的接口不一致，无法通过官方提供的测试APP的测试
-
第三次：加入API Rooter来将对外暴露的http接口在这一层进行统一
- 由API Rooter层通过GRPC去调用服务实际的业务逻辑
- API Rooter层组装api，对外提供http服务 / 直接内部组装好的接口暴露出去
- API Rooter层管理Token的认证
- 可能遇到的问题：API Rooter层是SPOF（单点故障）
-
未来畅想：引入一层网关技术（API Gateway）来处理转发用户的请求
- 为每个服务组件一个网关小组，单独处理他们提供的API
为什么go使用grpc作为微服务间通信方案
-
gRPC 先要定义服务接口，然后再去实现细节
- gRPC 可以约束多语言开发的分布式应用程序，使分布式应用程序更加可靠，可扩展。
-
gRPC 使用 protocol buffers 定义服务接口，可以支持多种语言
- 强制约束了不同语言的分布式应用程序之间进程间通信使用的类型，可以使分布式应用程序更加稳定。
-
缺点：因为 gRPC 具有接口契约和强类型等特点，会限制面向外部服务的灵活性，所以 gRPC 可能不适合面向外部的服务
使用redis缓存加速
我看到有的组采用了redis缓存加速的方案
- redis是NoSQL数据库
- redis具有极高的数据读写速度：数据读取的速度最高可达到110000次/s，数据写入速度最高可达到81000次/s
- redis支持数据的持久化：可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用
- redis基于内存运行并支持持久化，采用key-value（键值对）的存储形式，是目前分布式架构中不可或缺的一环
一些感想什么的
其实这次就是时间非常紧凑（要准备开学考试），所以基本上感觉除了OSS和联表查询没有用到什么新的东西（不过我也好久没写go了hhh），我的感觉就是组队之前要充分了解队员的技术栈。
