从零开始搭建框架(一)技术选型

凛冬王昭君 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.总结

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