从零开始搭建框架（一）技术选型

凛冬王昭君 2020年11月12日 381次浏览

1.开篇致辞

身为一个优秀的打工人，只有努力的工作，才能让老板更好地生活！而日益迭代的技术，已经不满足于老板的需求，老板考虑的是并不是技术能不能实现他的需求，而是能不能在规定的时间看到他想要的成果，这样你的能力才能得到老板的认可，但是随着现在技术更新太快，可能去年还满足的技术架构，但随着用户增长或者数据量扩大，导致原有的架构承受不住现在的业务体量。

在此，仅以一名技术专家的角度（咳咳，自封的，无须在意）来讲讲升级一个架构需要考虑的点。

2.你准备好了吗？

老板（甲）说：“你这产品不行啊，才十万就撑不住了，以后怎么放心把上亿的用户交给你啊？” 码农（乙） 心里想：“您就吹吧，还上亿，撑死了也就达到一百万就不错了！”

但真实情况下，肯定不敢这么说的，不然你就和这个公司拜拜了（咳咳，有点夸张）

2.1 破釜沉舟大可不必

如果真遇上这种情况，有的人可能会考虑加机器，有的人可能会考虑业务拆分，但是这种很容易出现代码重构或者代码量越来越庞大，越来越难以维护。

  • 目前市面上的技术框架很多，郭敬明在《演员2》说过：“存在即合理”，这句话用在此处，我也是非常的赞同，技术的出现也是因为某个瓶颈的产生，在大公司当中，或许你们听过，会有那种专门研究技术底层的专家团队，因为现有业务的现状，市面上的技术无法满足，所有有专家团队来研究底层架构，涌现出一批批优秀的技术框架（阿里的rocketmq，nacos，dubbo等等）

面对这么多优秀的技术框架，那么我们如何把控技术方向，如何进行技术选型呢？或者说我们如何能让老板快速的过上幸福美满的生活？

3. 技术选型

在此，我会分为20个方面来介绍一下现有的技术组件分类，涉及一个程序员各个方面的技术涵养以及功底

3.1 API网关

在现在的大环境下，网关必不可少，因为他是沟通前端与后端的桥梁

  • Spring Cloud Gateway
    是 Spring Cloud 新推出的网关框架，之前是 Netflix Zuul。网关通常在项目中为了简化前端的调用逻辑，同时也简化内部服务之间互相调用的复杂度；具体作用就是转发服务，接收并转发所有内外部的客户端调用；其他常见的功能还有权限认证，限流控制等等

  • Soul（国产微服务网关）
    基于 WebFlux 实现的响应式的 API 网关，具有异步、高性能、跨语言等特点。作者：我希望能够有一样东西像灵魂一样，保护您的微服务。在参考了 Kong、Spring Cloud Gateway 等优秀的网关后，站在巨人的肩膀上，Soul 由此诞生！

  • Zuul
    Zuul是spring cloud中的微服务网关。网关： 是一个网络整体系统中的前置门户入口。请求首先通过网关，进行路径的路由，定位到具体的服务节点上。

  • APISIX（国产微服务网关）
    APISIX 是基于 OpenResty + etcd 实现的云原生、高性能、可扩展的微服务 API 网关。它是国人进行开源，目前已经进入 Apache 进行孵化，为国人争光，实在是牛逼！！！

  • KONG
    Kong 是由 Mashape 公司开源的云原生、高性能、可扩展的微服务 API 网关。它基于 OpenResty 实现，使用 Cassandra 或 PostgreSQL 存储数据。其实很早关注了，算是很优秀的技术框架

  • NGINX
    Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器，在BSD-like 协议下发行。其特点是占有内存少，并发能力强，事实上nginx的并发能力在同类型的网页服务器中表现较好，中国大陆使用nginx网站用户有：百度、京东、新浪、网易、腾讯、淘宝等。

3.2 Java脚手架

  • spring
  • spring boot
  • spring cloud
  • quarkus

3.3 服务调用

随着分布式，微服务等新新理念的提出，服务拆分等走入潮流，这个时候服务调用显得尤为重要。比如订单服务和库存服务的交互，市面上常见的技术组件有以下几种，各有其优点

  • Dubbo
  • Ribbon+openfeign
  • gRPC
  • SOFA RPC
  • Motan

3.4 消息队列

消息队列常见的使用场景吧，其实有很多，但是比较核心的有 3 个：解耦、异步、削峰,在微服务中更显得尤为突出，成为使用微服务达到一定量级必备的技术组件。

  • RocketMQ
  • RabbitMQ
  • ActiveMQ
  • kafka

3.5 作业调度

定时任务想必大家都很熟悉，在一个系统中，几乎是必不可少，单机情况下不需要考虑很多，但是进入了微服务，分布式，高并发领域，原有的定时任务就很难支撑，比如幂等性，高并发场景，作业调度可能处理大量的高并发定时任务，对机器的要求越来越高，单机的定时任务很难达到，也很容易导致服务崩溃。

  • Quartz
  • Elastic Job
  • Elastic Job cloud
  • xxl-job
  • power-job

3.6 注册中心

  • eureka
  • Nacos
  • consul
  • zookeeper
  • etcd

3.7 配置中心

  • Apollo
  • Nacos
  • Spring Cloud Config
  • Disconf

3.8 链路追踪

  • SkyWalking
  • Zipkin
  • CAT（Central Application Tracking）
  • Pinpoint

3.9 服务保障

  • Hystrix
  • Sentinel
  • Resilience4j

3.10 安全框架

  • Spring Security
  • Apache Shiro
  • OAuth2.0

3.11 ORM框架

  • Mybatis
  • Mybatis plus
  • Hibernate
  • Spring Data JPA

3.12 数据库连接池

  • C3P0
  • BoneCP
  • DBCP
  • Proxool
  • HikariCP
  • Druid

3.13 数据库中间件

  • Sharding-JDBC
  • Sharding-Sphere
  • MyCAT
  • Canal

3.14 分布式事务

  • TCC-Transaction
  • Seata
  • Fescar
  • Happylifeplat-TCC

3.15 数据库

  • MySQL
  • Redis
  • MongoDB
  • TiDB
  • H2 database

3.16 搜索引擎

  • Elasticsearch
  • Solr
  • Lucene

3.17 工具类

  • Hutool
  • Guava

3.18 容器/部署

  • Docker
  • Docker-compose
  • Kubernetes
  • Jenkins
  • Harbor
  • Linux

3.19 监控体系

  • ELK
  • Prometheus + Grafana + Alertmanager
  • Spring Boot Admin
  • CAT（Central Application Tracking）
  • Sentry

3.20 服务器

  • Netty
  • Tomcat
  • Jetty
  • Nginx

4. 技术攻坚

面对我上面做的技术分类，基本上就可以在大脑里形成一个完成的技术选型图

接下来我们要做的就是对上面所涉及的领域技术做一个选择，但是首先你得先做到对上面的技术有个大体掌握，知其优缺点，结合具体业务场景选择合适的框架进行搭建，这是至关重要的

5. 思考

如果是你来搭建框架，你会如何进行考虑？

  • 首选你得对服务器资源，业务量进行预估，才能落地搭建地基，就跟建筑工程师一样，打好地基才是至关重要的。
  • 其次，我们得约定好开发模式，前后端响应规范，书写代码规范，代码结构等等，能达到优雅的代码，给人一种看着过瘾，流连忘返，情难自禁。
  • 接下来就是落地框架搭建，做好技术组件的选择，封装等等

6.总结

本篇是《从零开始搭建框架》系列的初导篇，后面会根据这么些技术框架分类进行具体对比，实现，选择，搭建属于自己的技术栈框架，优雅的为老板赚钱，加油，打工人，打工魂~

上一篇： 代理数据库