精华内容
参与话题
问答
  • 后端技术】从零开始在Ubuntu18.04上进行后端技术开发1、区分前端后端与前台后台2、搭建后端开发环境2.1 在Ubuntu18.04安装java8 jdk2.2 在Ubuntu18.04安装与配置Redis3.0+2.3 在Ubuntu18.04安装与配置Maven3.0+2.4...

    作为搞IT技术的,相信大家或多或少都了解过“前端”、“后端这个词”。本文正式开启作者的后端技术之路。在此之前,我没听说过“前后端分离”、“ajax”,说实话,刚入门后端开发,我相信大家都是无从下手的,因为要学习的东西太多太多,想走完整个开发流程实在很难。

    1、区分前端后端与前台后台

    2、搭建后端开发环境

    2.1 在Ubuntu18.04安装java8 jdk

    首先,执行如下安装命令:

    sudo apt-get install openjdk-8-jdk
    

    然后在提示[Y/n]处输入y确认安装
    在这里插入图片描述然后,在~/.bashrc配置Java环境变量:

    sudo vim ~/.bashrc
    

    打开文件后,在英文输入法状态下点击按键I,进入编辑模式,将光标移到最后,复制粘贴添加以下代码:

    # for java develop
    export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64
    export JRE_HOME=$JAVA_HOME/jre
    export CLASSPATH=$JAVA_HOME/lib:$JRE_HOME/lib:$CLASSPATH
    export PATH=$JAVA_HOME/bin:$JRE_HOME/bin:$PATH
    

    然后点击按钮esc,退出编辑模式,同时按住shift:按钮,进入vim的命令行模式,输入wq,然后点击回车键,即可保存并退出文件。
    在这里插入图片描述

    接着,执行如下命令让.bashrc文件的配置立即生效:

    source ~/.bashrc
    

    最后,检查是否安装成功:
    用java -version查看是否安装成功:

    java -version
    

    返回版本信息如下:
    在这里插入图片描述
    用javac 查看环境变量是否配置成功 :

    javac
    

    2.2 在Ubuntu18.04安装与配置Redis3.0+

    Redis (远程字典服务器Remote Dictionary Server)是一个开源的内存数据库,用作缓存和消息代理。它也被称为数据结构服务器。它与其他主要数据库的不同之处在于它能够存储高级数据类型(包括地图,列表,集合等),易于使用的界面,对数据进行原子操作以及其他人无法找到的出色性能现有数据库。

    首先更新源:

    sudo apt-get update
    

    接着运行安装命令:

    sudo apt-get install redis-server
    

    在这里插入图片描述然后在提示[Y/n]处输入y确认安装。

    为了检查Redis是否正确安装并正常工作,可以输入以下命令:

    redis-cli --version
    

    返回版本号如下:

    redis-cli 4.0.9
    

    完成安装后,可以使用以下命令检查Redis是否正在运行:

    sudo systemctl status redis
    

    在输出中,找到“ Active: active (running)“。

    ● redis-server.service - Advanced key-value store
       Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)
       Active: active (running) since Thu 2020-10-22 16:23:20 UTC; 4min 53s ago
         Docs: http://redis.io/documentation,
               man:redis-server(1)
     Main PID: 12689 (redis-server)
        Tasks: 4 (limit: 6143)
       CGroup: /system.slice/redis-server.service
               └─12689 /usr/bin/redis-server 127.0.0.1:6379
    
    Oct 22 16:23:20 gpu144 systemd[1]: Starting Advanced key-value store...
    Oct 22 16:23:20 gpu144 systemd[1]: redis-server.service: Can't open PID file /var/run/redis/redis-server.pid (yet?
    Oct 22 16:23:20 gpu144 systemd[1]: Started Advanced key-value store.
    lines 1-13/13 (END)
    

    如果尚未启动Redis,则可以通过输入以下命令来启动它:

    sudo systemctl start redis-server
    

    如果Redis已经在运行并且要停止它,则可以使用以下命令:

    sudo systemctl stop redis
    

    在Ubuntu上配置Redis服务器:

    Redis的默认配置位于/etc/redis/redis.conf中。 默认情况下,服务器侦听来自服务器上所有可用接口的连接。 您可以让它侦听您选择的接口,根据需要可以是一个或多个接口。 这可以通过使用绑定配置指令来完成,该指令后跟一个或多个IP地址。要指示Redis服务器侦听特定的IP地址,您需要编辑/etc/redis/redis.conf文件:

    sudo vim /etc/redis/redis.conf
    

    找到 bind 127.0.0.1 ::1
    在这里插入图片描述
    现在,通过输入您希望Redis服务器监听的接口的值来更改IP地址。 例如:

    bind 192.168.0.1
    

    如果您想添加多个IP地址,只需将它们用空格隔开即可:

    bind 192.168.0.1 192.168.0.2
    

    在这里您需要输入自己网络的IP地址。

    但是,如果希望服务器监听网络上的所有接口,则可以使用以下命令:

    bind 0.0.0.0
    

    完成更改后,点击按钮esc,退出编辑模式,同时按住shift:按钮,进入vim的命令行模式,输入wq,然后点击回车键,即可保存并退出文件。

    最后,执行重新启动Redis服务器以应用更改:

    sudo systemctl restart redis-server
    

    2.3 在Ubuntu18.04安装与配置Maven3.0+

    如果要使用spring boot2,就需要使用到Maven,在这里介绍了如何在ubuntu18.04下安装Maven。

    首先,在本地存储库中查看Maven软件包的版本:

    sudo apt policy maven
    

    返回结果如下:

    maven:
      Installed: (none)
      Candidate: 3.6.0-1~18.04.1
      Version table:
         3.6.0-1~18.04.1 500
            500 http://archive.ubuntu.com/ubuntu bionic-updates/universe amd64 Packages
            500 http://archive.ubuntu.com/ubuntu bionic-security/universe amd64 Packages
         3.5.2-2 500
            500 http://archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
    

    然后,运行安装命令,如下:

    sudo apt install maven
    

    最后,运行以下命令验证安装是否成功:

    mvn -version
    

    返回如下版本信息:

    Apache Maven 3.6.0
    Maven home: /usr/share/maven
    Java version: 1.8.0_265, vendor: Private Build, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre
    Default locale: en_US, platform encoding: UTF-8
    OS name: "linux", version: "4.15.0-118-generic", arch: "amd64", family: "unix"
    

    2.4 在Ubuntu18.04安装与配置MYSQL 5.7

    首先看一下系统中是否存在mysql相关的安装包,命令如下

    rpm -qa|grep mysql
    

    如果存在mysql相关的安装包使用以下命令删除。

    sudo rpm -e --nodeps mysql-libs-xxxxxx 
    

    接着安装MYSQL 5.7:

    sudo apt-get install mysql-server
    

    在这里插入图片描述然后在提示[Y/n]处输入y确认安装。

    接着,启动mysql服务:

    service mysql start
    

    3.登录mysql

    mysql -u root -p
    

    此时会报错:

    Enter password:
    ERROR 1698 (28000): Access denied for user 'root'@'localhost'
    

    我们先进入root模式:

    sudo su
    

    在root模式下进入mysql:

    mysql -u root -p
    

    在这里插入图片描述

    输入如下命令查看表并修改密码:

    select user, plugin from mysql.user;
    

    在这里插入图片描述修改密码(请注意,不要设置数据库密码和服务器密码一样):

    update mysql.user set authentication_string=PASSWORD('123456'), plugin='mysql_native_password' where user='root';
    

    再次输入如下命令查看表密码:

    select user, plugin from mysql.user;
    

    在这里插入图片描述最后,完成密码设置并退出mysql:

    flush privileges; #使密码生效
    exit;  #退出mysql
    

    重启mysql服务:

    service mysql restart
    

    2.5 在Ubuntu18.04安装Node v8+与npm

    参考文章:https://www.howtoing.com/how-to-install-node-js-on-ubuntu-18-04

    Ubuntu 18.04在其默认存储库中包含一个版本的Node.js,可用于在多个系统间提供一致的体验。 在撰写本文时,存储库中的版本是8.10.0。 这不会是最新的版本,但它应该稳定且足以快速实验该语言。

    要获得此版本,您可以使用apt软件包管理器。 键入以下内容刷新本地包索引:

    sudo apt update
    

    从存储库安装Node.js:

    sudo apt install nodejs
    

    如果存储库中的软件包满足您的需求,则只需使用Node.js即可完成设置。 在大多数情况下,您还需要安装npm ,Node.js包管理器。 你可以通过输入以下命令来完

    sudo apt install npm
    

    这将允许您安装模块和程序包以与Node.js一起使用。

    由于与另一个软件包冲突,Ubuntu存储库中的可执行文件被称为nodejs而不是node 。 在运行软件时请记住这一点。

    要检查在这些初始步骤后安装了哪个版本的Node.js,请键入:

    nodejs -v
    

    检查npm是否成功安装:

    npm -v
    

    安装cnpm

    npm install -g cnpm --registry=https://registry.npm.taobao.org
    

    3、找一个现成的系统级别的开源项目

    这里我推荐两个项目:

    3.1 萤火小程序商城

    萤火小程序商城是B2C模式的电子商城,是在Thinkphp5基础上搭建的一个PHP项目,前后端全部开源。Thinkphp5以易学易用著称,同时也方便二次开发,让您快速搭建个性化独立商城。
    https://www.yiovo.com/
    https://gitee.com/xany/bestshop-php

    3.2 yshop意象商城系统

    yshop基于当前流行技术组合的前后端分离商城系统: SpringBoot2+MybatisPlus+SpringSecurity+jwt+redis+Vue的前后端分离的商城系统, 包含商城、拼团、砍价、商户管理、 秒杀、优惠券、积分、分销、会员、充值、多门店等功能
    https://doc.yixiang.co/
    https://gitee.com/guchengwuyue/yshopmall

    【作者简介】陈艺荣,男,目前在华南理工大学电子与信息学院广东省人体数据科学工程技术研究中心攻读博士,担任IEEE Access、IEEE Photonics Journal的审稿人。两次获得美国大学生数学建模竞赛(MCM)一等奖,获得2017年全国大学生数学建模竞赛(广东赛区)一等奖、2018年广东省大学生电子设计竞赛一等奖等科技竞赛奖项,主持一项2017-2019年国家级大学生创新训练项目获得优秀结题,参与两项广东大学生科技创新培育专项资金、一项2018-2019年国家级大学生创新训练项目获得良好结题,发表SCI论文4篇,授权实用新型专利8项,受理发明专利13项。
    我的主页
    我的Github
    我的CSDN博客
    我的Linkedin

    展开全文
  • Java后端技术栈笔记

    2020-04-20 23:07:31
    java后端技术栈笔记包括一些常用技术 欢迎一起学习
  • 后端技术演进

    2017-03-07 00:31:00
  • 后端技术体系框架

    2019-06-23 17:50:00
    转自:https://juejin.im/post/5b59324ef265da0f69703f40,这是一篇非常好的讲解后端技术体系的文章,能让你对后端技术体系有个大概的轮廓。 这边我推荐我看过的一本书 曾宪杰《大型网站系统与Java中间件实践》,...

    转自:https://juejin.im/post/5b59324ef265da0f69703f40,这是一篇非常好的讲解后端技术体系的文章,能让你对后端技术体系有个大概的轮廓。

    这边我推荐我看过的一本书 曾宪杰《大型网站系统与Java中间件实践》,对于后端的一些服务如何从单机到分布式讲解是非常深入的,让你能够对后端各个层次的中间件框架有着进一步的理解。

    1、后端技术体系框架

    使用Java后端技术的目的就是构建业务应用,为用户提供在线或者离线服务。因此,一个业务应用需要哪些技术、依赖哪些基础设施就决定了需要掌握的后端技术有哪些。纵观整个互联网技术体系再结合公司的目前状况,笔者认为必不可少或者非常关键的后端基础技术/设施如下图所示:
    后端技术体系
    这里的后端基础设施主要指的是应用在线上稳定运行需要依赖的关键组件或者服务。开发或者搭建好以上的后端基础设施,一般情况下是能够支撑很长一段时间内的业务的。此外,对于一个完整的架构来说,还有很多应用感知不到的系统基础服务,如负载均衡、自动化部署、系统安全等,并没有包含在本章的描述范围内。

    2、统一请求入口-API网关

    在移动 APP 的开发过程中,通常后端提供的接口需要以下功能的支持:

    • 负载均衡
    • API 访问权限控制
    • 用户鉴权

    一般的做法,使用 Nginx 做负载均衡,然后在每个业务应用里做 API 接口的访问权限控制和用户鉴权,更优化一点的方式则是把后两者做成公共类库供所有业务调用。但从总体上来看,这三种特性都属于业务的公共需求,更可取的方式则是集成到一起作为一个服务,既可以动态地修改权限控制和鉴权机制,也可以减少每个业务集成这些机制的成本。这种服务就是 API 网关,可以选择自己实现。也可以使用开源软件实现,如 Kong 和 Netflix Zuul。API 网关一般架构如下图所示:

    但是以上方案的一个问题是由于所有 API 请求都要经过网关,它很容易成为系统的性能瓶颈。因此,可以采取的方案是:去掉 API 网关,让业务应用直接对接统一认证中心,在基础框架层面保证每个 API 调用都需要先通过统一认证中心的认证,这里可以采取缓存认证结果的方式避免对统一认证中心产生过大的请求压力。

    3、统一认证中心

    统一认证中心,主要是对 APP 用户、内部用户、APP 等的认证服务,包括

    • 用户的注册、登录验证、Token 鉴权
    • 内部信息系统用户的管理和登录鉴权
    • APP 的管理,包括 APP 的 secret 生成,APP 信息的验证(如验证接口签名)等。

    之所以需要统一认证中心,就是为了能够集中对这些所有APP都会用到的信息进行管理,也给所有应用提供统一的认证服务。尤其是在有很多业务需要共享用户数据的时候,构建一个统一认证中心是非常必要的。此外,通过统一认证中心构建移动APP的单点登录也是水到渠成的事情:模仿 Web 的机制,将认证后的信息加密存储到本地存储中供多个 APP 使用。

    4、单点登录系统

    目前很多大的在线 Web 网站都是有单点登录系统的,通俗的来说就是只需要一次用户登录,就能够进入多个业务应用(权限可以不相同),非常方便用户的操作。而在移动互联网公司中,内部的各种管理、信息系统甚至外部应用同样也需要单点登录系统。

    目前,比较成熟的、用的最多的单点登录系统应该是耶鲁大学开源的CAS, 可以基于 https://github.com/apereo/cas/tree/master/cas-server-webapp 来定制开发的。

    基本上,单点登录的原理都类似下图所示:


    5、统一配置中心

    在 Java 后端应用中,一种读写配置比较通用的方式就是将配置文件写在 Propeties、YAML、HCON 等文件中,修改的时候只需要更新文件重新部署即可,可以做到不牵扯代码层面改动的目的。统一配置中心,则是基于这种方式之上的统一对所有业务或者基础后端服务的相关配置文件进行管理的统一服务, 具有以下特性:

    • 能够在线动态修改配置文件并生效
    • 配置文件可以区分环境(开发、测试、生产等)
    • 在 Java 中可以通过注解、XML 配置的方式引入相关配置

    百度开源的 Disconf 和携程的 Apollo 是可以在生产环境使用的方案,也可以根据自己的需求开发自己的配置中心,一般选择 Zookeeper 作为配置存储。

    6、服务治理框架

    对于外部 API 调用或者客户端对后端 API 的访问,可以使用 HTTP 协议或者 RESTful(当然也可以直接通过最原始的socket来调用)。但对于内部服务间的调用,一般都是通过 RPC 机制来调用的。目前主流的 RPC 协议有:

    • RMI
    • Hessian
    • Thrift
    • Dubbo

    这些 RPC 协议各有优劣点,需要针对业务需求做出最好的选择。

    这样,当你的系统服务在逐渐增多,RPC 调用链越来越复杂,很多情况下,需要不停的更新文档来维护这些调用关系。一个对这些服务进行管理的框架可以大大减少因此带来的繁琐的人力工作。

    传统的 ESB(企业服务总线)本质就是一个服务治理方案,但 ESB 作为一种 proxy 的角色存在于 Client 和 Server 之间,所有请求都需要经过 ESB,使得 ESB 很容易成为性能瓶颈。因此,基于传统的ESB,更好的一种设计如下图所示:

    如图,以配置中心为枢纽,调用关系只存在于 Client 和提供服务的 Server 之间,就避免了传统 ESB 的性能瓶颈问题。对于这种设计,ESB 应该支持的特性如下:

    • 服务提供方的注册、管理
    • 服务消费者的注册、管理
    • 服务的版本管理、负载均衡、流量控制、服务降级、资源隔离
    • 服务的容错、熔断

    阿里开源的 Dubbo 则对以上做了很好的实现,也是目前很多公司都在使用的方案;当当网的扩展项目 Dubbox 则在 Dubbo 之上加入了一些新特性。目前,Dubbo 已经被阿里贡献给 Apache,处于incubating 状态。在运维监控方面,Dubbo 本身提供了简单的管理控制台 dubbo-admin 和监控中心 dubbo-monitor-simple。Github 上的 dubboclub/dubbokeeper 则是在其之上开发的更为强大的集管理与监控于一身的服务管理以及监控系统。

    此外,Netflix 的 Eureka 也提供了服务注册发现的功能,其配合 Ribbon 可以实现服务的客户端软负载均衡,支持多种灵活的动态路由和负载均衡策略。

    7、统一调度中心

    在很多业务中,定时调度是一个非常普遍的场景,比如定时去抓取数据、定时刷新订单的状态等。通常的做法就是针对各自的业务依赖 Linux 的 Cron 机制或者 Java 中的 Quartz。统一调度中心则是对所有的调度任务进行管理,这样能够统一对调度集群进行调优、扩展、任务管理等。Azkaban 和 Yahoo 的 Oozie 是 Hadoop 的流式工作管理引擎,也可以作为统一调度中心来使用。当然,你也可以使用Cron或者Quartz来实现自己的统一调度中心。

    • 根据 Cron 表达式调度任务
    • 动态修改、停止、删除任务
    • 支持任务分片执行
    • 支持任务工作流:比如一个任务完成之后再执行下一个任务
    • 任务支持脚本、代码、url等多种形式
    • 任务执行的日志记录、故障报警

    对于 Java 的 Quartz 这里需要说明一下:这个 Quartz 需要和 Spring Quartz 区分,后者是 Spring 对 Quartz 框架的简单实现也是目前使用的最多的一种调度方式。但其并没有做高可用集群的支持。而 Quartz 虽然有集群的支持,但是配置起来非常复杂。现在很多方案都是使用 Zookeeper 来实现 Spring Quartz 的分布式集群。

    此外,当当网开源的 elastic-job 则在基础的分布式调度之上又加入了弹性资源利用等更为强大的功能。

    8、统一日志服务

    日志是开发过程必不可少的东西。打印日志的时机、技巧是很能体现出工程师编码水平的。毕竟,日志是线上服务能够定位、排查异常最为直接的信息。

    通常的,将日志分散在各个业务中非常不方便对问题的管理和排查。统一日志服务则使用单独的日志服务器记录日志,各个业务通过统一的日志框架将日志输出到日志服务器上。

    可以通过实现 Log4j 或者 Logback 的 Appender 来实现统一日志框架,然后通过 RPC 调用将日志打印到日志服务器上。

    9、业务应用和后端基础框架

    业务应用分为:在线业务应用和内部业务应用。

    • 在线业务应用:直接面向互联网用户的应用、接口等,典型的特点就是:请求量大、高并发、对故障的容忍度低。
    • 内部业务应用:主要面向公司内部用户的应用。比如,内部数据管理平台、广告投放平台等。相比起在线业务应用,其特点: 数据保密性高、压力小、并发量小、允许故障的发生。

    业务应用基于后端的基础框架开发,针对 Java 后端来说,应该有以下几个框架:

    • MVC 框架:统一开发流程、提高开发效率、屏蔽一些关键细节的 Web/后端框架。典型的如 SpringMVC、Jersey 以及国人开发的 JFinal 以及阿里的 WebX。
    • IOC 框架:实现依赖注入/控制反转的框架。Java 中最为流行的 Spring 框架的核心就是 IOC 功能。
    • ORM 框架:能够屏蔽底层数据库细节,提供统一的数据访问接口的数据库操作框架,额外地能够支持客户端主从、分库、分表等分布式特性。MyBatis 是目前最为流行的 ORM 框架。此外,Spring ORM 中提供的 JdbcTemplate 也很不错。当然,对于分库分表、主从分离这些需求,一般就需要自己实现,开源的则有阿里的 TDDL、当当的 sharding-jdbc(从datasource层面解决了分库分表、读写分离的问题,对应用透明、零侵入)。此外,为了在服务层面统一解决分库分表、读写分离、主备切换、缓存、故障恢复等问题,很多公司都是有自己的数据库中间件的,比如阿里的 Cobar、360的 Atlas(基于MySQL-Proxy)、网易的 DDB 、美团的 zebra等;开源的则有 MyCat(基于Cobar)和 Kingshard ,其中 Kingshard 已经有一定的线上使用规模。MySQL 官方也提供了 MySQL Proxy, 可以使用 lua 脚本自定义主从、读写分离、分区这些逻辑,但其性能较差,目前使用较少。
    • 缓存框架:对 Redis、Memcached 这些缓存软件操作的统一封装,能够支持客户端分布式方案、主从等。一般使用 Spring 的 RedisTemplate 即可,也可以使用 Jedis 做自己的封装,支持客户端分布式方案、主从等。
    • JavaEE 应用性能检测框架:对于线上的JavaEE应用,需要有一个统一的框架集成到每一个业务中检测每一个请求、方法调用、JDBC 连接、Redis 连接等的耗时、状态等。Jwebap 是一个可以使用的性能检测工具,但由于其已经很多年没有更新,有可能的话建议基于此项目做二次开发。

    一般来说,以上几个框架即可以完成一个后端应用的雏形。

    10、缓存、数据库、搜索引擎、消息队列

    缓存、数据库、搜索引擎、消息队列这四者都是应用依赖的后端基础服务,他们的性能直接影响到了应用的整体性能,有时候你代码写的再好也许就是因为这些服务导致应用性能无法提升上去。

    • 缓存: 缓存通常被用来解决热点数据的访问问题,是提高数据查询性能的强大武器。在高并发的后端应用中,将数据持久层的数据加载到缓存中,能够隔离高并发请求与后端数据库,避免数据库被大量请求击垮。目前常用的除了在内存中的本地缓存,比较普遍的集中缓存软件有 Memcached 和 Redis。其中 Redis 已经成为最主流的缓存软件。
    • 数据库:数据库可以说是后端应用最基本的基础设施。基本上绝大多数业务数据都是持久化存储在数据库中的。主流的数据库包括传统的关系型数据库(MySQL、PostgreSQL)以及最近几年开始流行的 NoSQL(MongoDB、HBase)。其中 HBase 是用于大数据领域的列数据库,受限于其查询性能,一般并不用来做业务数据库。
    • 搜索引擎:搜索引擎是针对全文检索以及数据各种维度查询设计的软件。目前用的比较多的开源软件是 Solr 和 Elasticsearch,都是基于 Lucence 来实现的,不同之处主要在于 termIndex 的存储、分布式架构的支持等。Elasticsearch 由于对集群的良好支持以及高性能的实现,已经逐渐成为搜索引擎的主流开源方案。
    • 消息队列:数据传输的一种方式就是通过消息队列。目前用的比较普遍的消息队列包括为日志设计的 Kafka 以及重事务的 RabbitMQ 等。在对消息丢失不是特别敏感且并不要求消息事务的场景下,选择 Kafka 能够获得更高的性能;否则,RabbitMQ 则是更好的选择。此外,ZeroMQ 则是一种实现消息队列的网络编程 Pattern 库,位于 Socket 之上,MQ 之下。

    11、文件存储

    不管是业务应用、依赖的后端服务还是其他的各种服务,最终还是要依赖于底层文件存储的。通常来说,文件存储需要满足的特性有:可靠性、容灾性、稳定性,即要保证存储的数据不会轻易丢失,即使发生故障也能够有回滚方案,也要保证高可用。在底层可以采用传统的 RAID 作为解决方案,再上一层,目前 Hadoop 的 HDFS 则是最为普遍的分布式文件存储方案,当然还有 NFS、Samba 这种共享文件系统也提供了简单的分布式存储的特性。

    此外,如果文件存储确实成为了应用的瓶颈或者必须提高文件存储的性能从而提升整个系统的性能时,那么最为直接和简单的做法就是抛弃传统机械硬盘,用 SSD 硬盘替代。像现在很多公司在解决业务性能问题的时候,最终的关键点往往就是 SSD。这也是用钱换取时间和人力成本最直接和最有效的方式。在数据库部分描述的 SSDB 就是对 LevelDB 封装之后,利用 SSD 硬盘的特性的一种高性能 KV 数据库。

    至于 HDFS,如果要使用上面的数据,是需要通过 Hadoop 的。类似 xx on Yarn 的一些技术就是将非 Hadoop 技术跑在 HDFS 上的解决方案。

    12、数据基础设施

    数据是最近几年非常火的一个领域。从《精益数据分析》到《增长黑客》,都是在强调数据的非凡作用。很多公司也都在通过数据推动产品设计、市场运营、研发等。这里需要说明的一点是,只有当你的数据规模真的到了单机无法处理的规模才应该上大数据相关技术,千万不要为了大数据而大数据。很多情况下使用单机程序 +MySQL 就能解决的问题非得上 Hadoop 即浪费时间又浪费人力。

    这里需要补充一点的是,对于很多公司,尤其是离线业务并没有那么密集的公司,在很多情况下大数据集群的资源是被浪费的。因此诞了 xx on Yarn 一系列技术让非 Hadoop 系的技术可以利用大数据集群的资源,能够大大提高资源的利用率,如 Dockeron Yarn。

    数据高速公路

    接着上面讲的统一日志服务,其输出的日志最终是变成数据到数据高速公路上供后续的数据处理程序消费的。这中间的过程包括日志的收集和传输。

    • 收集:统一日志服务将日志打印在日志服务上之后,需要日志收集机制将其集中起来。目前,常见的日志收集方案有:Scribe、Chukwa、Kakfa 和 Flume。对比如下图所示:

    此外,Logstash 也是一个可以选择的日志收集方案,不同于以上的是,它更倾向于数据的预处理,且配置简单、清晰,经常以ELK(Elasticsearch + Logstash + Kibana)的架构用于运维场景中。
    • 传输:通过消息队列将数据传输到数据处理服务中。对于日志来说,通常选择 Kafka 这个消息队列即可。

    此外,这里还有一个关键的技术就是数据库和数据仓库间的数据同步问题,即将需要分析的数据从数据库中同步到诸如 Hive 这种数据仓库时使用的方案。可以使用 Apache Sqoop 进行基于时间戳的数据同步,此外,阿里开源的 Canal 实现了基于 binlog 增量同步,更加适合通用的同步场景,但是基于 Canal 还是需要做不少的业务开发工作。

    离线数据分析

    离线数据分析是可以有延迟的,一般针对的是非实时需求的数据分析工作,产生的也是延迟一天的报表。目前最常用的离线数据分析技术除了 Hadoop 还有 Spark。相比 Hadoop,Spark 性能上有很大优势,当然对硬件资源要求也高。其中,Hadoop 中的 Yarn 作为资源管理调度组件除了服务于 MR 还可以用于 Spark(Spark on Yarn),Mesos 则是另一种资源管理调度系统。

    对于 Hadoop,传统的 MR 编写很复杂,也不利于维护,可以选择使用 Hive 来用 SQL 替代编写 MR。而对于 Spark,也有类似 Hive 的 Spark SQL。

    此外,对于离线数据分析,还有一个很关键的就是数据倾斜问题。所谓数据倾斜指的是 region 数据分布不均,造成有的结点负载很低,而有些却负载很高,从而影响整体的性能。处理好数据倾斜问题对于数据处理是很关键的。

    实时数据分析

    相对于离线数据分析,实时数据分析也叫在线数据分析,针对的是对数据有实时要求的业务场景,如广告结算、订单结算等。目前,比较成熟的实时技术有 Storm 和 Spark Streaming。相比起Storm,Spark Streaming 其实本质上还是基于批量计算的。如果是对延迟很敏感的场景,还是应该使用 Storm。除了这两者,Flink 则是最近很火的一个分布式实时计算框架,其支持 Exactly Once的语义,在大数据量下具有高吞吐低延迟的优势,并且能够很好的支持状态管理和窗口统计,但其文档、API管理平台等都还需要完善。

    实时数据处理一般情况下都是基于增量处理的,相对于离线来说并非可靠的,一旦出现故障(如集群崩溃)或者数据处理失败,是很难对数据恢复或者修复异常数据的。因此结合离线+实时是目前最普遍采用的数据处理方案。Lambda架构就是一个结合离线和实时数据处理的架构方案。

    此外,实时数据分析中还有一个很常见的场景:多维数据实时分析,即能够组合任意维度进行数据展示和分析。目前有两种解决此问题的方案:ROLAP 和 MOLAP。

    • ROLAP:使用关系型数据库或者扩展的关系型数据库来管理数据仓库数据,以Hive、Spark SQL、Presto为代表。
    • MOLAP:基于数据立方体的多位存储引擎,用空间换时间,把所有的分析情况都物化为物理表或者视图。以Druid、Pinot和Kylin为代表,不同于ROLAP(Hive、Spark SQL), 其原生的支持多维的数据查询。

    如上一小节所述,ROLAP的方案大多数情况下用户离线数据分析,满足不了实时的需求,因此 MOLAP 是多维数据实时分析的常用方案。对于其中常用的三个框架,对比如下:

    其中,Druid相对比较轻量级,用的人较多,比较成熟。

    数据即席分析

    离线和实时数据分析产生的一些报表是给数据分析师、产品经理参考使用的,但是很多情况下,线上的程序并不能满足这些需求方的需求。这时候就需要需求方自己对数据仓库进行查询统计。针对这些需求方,SQL上手容易、易描述等特点决定了其可能是一个最为合适的方式。因此提供一个 SQL 的即席查询工具能够大大提高数据分析师、产品经理的工作效率。Presto、Impala、Hive 都是这种工具。如果想进一步提供给需求方更加直观的 ui 操作界面,可以搭建内部的 Hue。

    13、故障监控

    对于面向用户的线上服务,发生故障是一件很严重的事情。因此,做好线上服务的故障检测告警是一件非常重要的事情。可以将故障监控分为以下两个层面的监控:

    • 系统监控:主要指对主机的带宽、CPU、内存、硬盘、IO等硬件资源的监控。可以使用 Nagios、Cacti 等开源软件进行监控。目前,市面上也有很多第三方服务能够提供对于主机资源的监控,如监控宝等。对于分布式服务集群(如 Hadoop、Storm、Kafka、Flume 等集群)的监控则可以使用Ganglia。此外,小米开源的 OpenFalcon 也很不错,涵盖了系统监控、JVM监控、应用监控等,也支持自定义的监控机制。
    • 业务监控:是在主机资源层面以上的监控,比如 APP 的 PV、UV 数据异常、交易失败等。需要业务中加入相关的监控代码,比如在异常抛出的地方,加一段日志记录。

    监控还有一个关键的步骤就是告警。告警的方式有很多种:邮件、IM、短信等。考虑到故障的重要性不同、告警的合理性、便于定位问题等因素,有以下建议:

    • 告警日志要记录发生故障的机器 IP,尤其是在集群服务中,如果没有记录机器 IP,那么对于后续的问题定位会很困难。
    • 要对告警做聚合,不要每一个故障都单独进行告警,这样会对工程师造成极大的困扰。
    • 要对告警做等级划分,不能对所有告警都做同样的优先级处理。
    • 使用微信做为告警软件,能够在节省短信成本的情况下,保证告警的到达率。

    故障告警之后,那么最最关键的就是应对了。对于创业公司来说,24小时待命是必备的素质,当遇到告警的时候,需要尽快对故障做出反应,找到问题所在,并能在可控时间内解决问题。对于故障问题的排查,基本上都是依赖于日志的。只要日志打的合理,一般情况下是能够很快定位到问题所在的,但是如果是分布式服务,并且日志数据量特别大的情况下,如何定位日志就成为了难题。这里有几个方案:

    • 建立ELK(Elasticsearch + Logstash + Kibana)日志集中分析平台,便于快速搜索、定位日志。搭配 Yelp 开源的 Elastalert 可以实现告警功能。
    • 建立分布式请求追踪系统(也可以叫全链路监测系统),对于分布式系统尤是微服务架构,能够极大的方便在海量调用中快速定位并收集单个异常请求信息,也能快速定位一条请求链路的性能瓶颈。唯品会的 Mercury、阿里的鹰眼、新浪的 WatchMan、Twitter 开源的 Zipkin 基本都是基于 Google 的 Dapper 论文而来,大众点评的实时应用监控平台 CAT 则在支持分布式请求追踪(代码侵入式)的基础上加入了细粒度的调用性能数据统计。此外,Apache 正在孵化中的 HTrace 则是针对大的分布式系统诸如 HDFS 文件系统、HBase 存储引擎而设计的分布式追踪方案。而如果你的微服务实现使用了 Spring Cloud,那么 Spring Cloud Sleuth 则是最佳的分布式跟踪方案。还需要提到的是,Apache 孵化中的 SkyWalking 是基于分布式追踪的一个完备的APM(应用性能监测)系统,其最大的一个特点就是基于 Java agent + instrument api,对业务代码无任何侵入,Pinpoint则是类似的另一个已经用于生产环境的 APM 系统。

    转载于:https://www.cnblogs.com/loren-Yang/p/11073536.html

    展开全文
  • app 后端技术

    2014-09-25 01:31:00
    app 后端技术 一直以来工作的方向是web server,对app server没有什么了解。虽然没有接触过移动app开发,但对app后端技术还是挺有探索欲望的,app应用和web应用在前端的用户习惯不同,相信后端也会有很多不太一样...

    app 后端技术

     

    一直以来工作的方向是web server,对app server没有什么了解。虽然没有接触过移动app开发,但对app后端技术还是挺有探索欲望的,app应用和web应用在前端的用户习惯不同,相信后端也会有很多不太一样的地方。开此文记录一些网上收集到的app后端技术体系,以备了解。

     

    下面就app server在业务设计上通常需要考虑的几个方面:

     

    1、api风格

    如何设计一套合理且优雅的api接口集,可以参考Restful分格:

    • api采用http(s)协议与前端通信;
    • 每个uri代表一种资源(resource),对于资源的操作类型,由HTTP方法表示(如GET、POST、PUT等)。例如:
    GET /zoos:            列出所有动物园
    POST /zoos:           新建一个动物园
    GET /zoos/ID:          获取某个指定动物园的信息
    PUT /zoos/ID:               更新某个指定动物园的信息(提供该动物园的全部信息)
    DELETE /zoos/ID:            删除某个动物园
    GET /zoos/ID/animals:       列出某个指定动物园的所有动物
    DELETE /zoos/ID/animals/ID: 删除某个指定动物园的指定动物    
    • 通过参数过滤结果,例如
    ?limit=10:         指定返回记录的数量
    ?offset=10:        指定返回记录的开始位置。
    ?sortby=name&order=asc: 指定返回结果按照哪个属性排序,以及排序顺序。
    ?animal_type_id=1:    指定筛选条件

     

    • 服务器返回的数据格式尽量采用json;
    • API身份认证key采用OAuth 2.0框架;
    • 返回错误码和错误消息,方便前端进行错误处理和异常保护;

     

     

    2、聊天服务

    聊天服务端选用openfile,这是一个基于xmpp协议的聊天服务器。
    xmpp除了提供聊天服务外,还可以充当消息服务器。

     

     

    3、短信、邮件、推送服务

    首先,各种消息推送一定要放在队列中处理,不然会严重影响api的响应时间。

     

    手机短信方面:

    通常要使用一些第三方短信服务平台提供的接口,这个没什么好说的;

     

    email方面:

    要考虑邮件发送失败的重发问题,所以不再在服务器上搭建sendmail服务发送,选择了邮件服务商mailgun。mailgun还提供每个账号每月1万封邮件的免费额度,很适合创业团队。

     

    消息推送方面:

    1、apns是iphone推送的不二选择。但如果自身开发apns的服务,会遇到无效token而需要重发,这样需要维护一个队列并建立重发机制。

    当用户在iphone上卸载了app后,device token会失效,所以应该定期访问苹果的feedback服务器,把无效的token去掉。

    2、android方面,有google的C2DM平台,但C2DM服务器在国外,国内用起来好像不太可用;

     

     

    4、LBS

    在LBS的应用中,一个基本的需求是查找附近的用户(或商户),现在有两种做法:

    1. 使用mysql的空间数据库,具体做法参考:http://blog.sina.com.cn/s/blog_a48af8c001018q1p.html 。

    2. 使用geohash编码。

     

    关于geohash编码,它把球面上的经纬度转换成一个值,简单点来说就是把二维坐标转换成一维坐标。查找附近的时候,非常方便,用SQL中,LIKE ‘w23yr3%’可查询附近的所有地点。

    当检索数据量特别大的时候,采用 coreseek+redis+mysql 可以解决查询慢的问题;

    PS:coreseek是一个基于Sphinx的全文检索引擎。

     

    5、动态通知

    通常很多app的右上角能看到一个小红圈,圈里面有一个数字,表示有多少条新消息到达,借此唤醒用户的打开欲望。

    在app端,怎么才能知道有多少条新通知呢?实现的技术有两种:

    1. polling:app定时查询

    2. push:服务器实时推送给app

    相对来说,push的方式更高效,避免app频繁去查询服务器,既增加了服务器的压力,又多消耗了自己的流量和电量。

     

    6、数据增量更新

     

     

    7、安全性

    用户和后端服务器通信的数据不要采用明文传输,尤其是涉及用户的帐号、密码这些敏感信息。

    比如用户登录过程可以使用ssl 协议交换数据。

    之前我自己在港交所的行情接收项目中采用过 Diffie-Hellman 算法,就是一种不错的密钥交换算法:

     

     

    参考文档:

    1、曾健生, 《app后端》 http://blog.csdn.net/newjueqi/article/category/1743543

    2、阮一峰,《RESTful API设计指南》 http://www.ruanyifeng.com/blog/2014/05/restful_api.html

    3、《查找附近的xxx 球面距离以及Geohash方案探讨》 http://www.wubiao.info/372

    4、《XMPP协议实现原理介绍》  http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378956.html

     

    转载于:https://www.cnblogs.com/chenny7/p/3991925.html

    展开全文
  • 后端技术栈规划

    2019-10-16 17:23:51
    不论做什么都需要好的规划后端技术图谱(后期更新不断补上链接) 后端技术图谱(后期更新不断补上链接) 数据结构 队列 集合 链表、数组 字典、关联数组 栈 树 二叉树 完全二叉树 平衡二叉树 二叉查找树(BST) ...
  • 后端技术官网集合 技术 名称 官网 Spring Framework 容器 http://projects.spring.io/spring-framework/ SpringMVC MVC框架 ...Apach...
  • 后端技术栈科普 前言 由于我毕业设计做基于Java的在线小说发布系统,所以前后端都有涉及。虽然以前端为主,但是后端的科普还是需要的。好久没碰后端了,对后端有些生疏了。 参考文章:Java开源项目之「自学编程之路...
  • java后端技术

    千次阅读 2019-03-11 13:28:59
    文章目录Java基础数据结构算法设计模式单例模式工厂模式数据库框架...java后端技术栈 Java基础 数据结构 算法 设计模式 单例模式 工厂模式 数据库 框架 Spring IOC AOP Spring MVC Mybatis 分布式系统 大数据...
  • 瓜子二手车高级技术总监纪鹏程在2017PHP全球开发者大会上做了主题为《瓜子后端技术架构的变迁》的演讲,就瓜子及二手车业务流程介绍,架构变迁过程的经验与教训,EP的实践⼯作做了深入分析。
  • TOP后端技术上线啦

    2020-03-01 16:40:07
    TOP后端技术上线啦!做一个专业化、系统化的知识分享平台。 http://toplist.pub 本站主题 从一个Java程序员/架构师的角度出发,总结需要掌握的后端技术、工作中遇到的问题,也会分享建站过程中的经验: Java 分布式...
  • Java后端技术栈梳理

    2019-10-18 10:38:05
    Java后端技术栈梳理(阅读量1.8k,讲的过去宏观) Java 后端自学之路(阅读量3.1w,71赞) 自学java心路历程(学了半年)(阅读量6.3k,47赞) 我的 Java 自学之路(阅读量5k) Java后端学习路线图,你真的只...
  • 之前创建了几个后端技术交流群,提供一个技术交流,问答及聊天的平台,很多群内的童鞋反馈是有帮助的,比较有意义。这次针对用的比较多的SpringBoot框架建一个群聊,群内可以主要和大家讨论...
  • 本次分享面向广大的后端技术开发人员,以 Java 编程语言为切入点,按照不同的技术切面逐步分享,煌煌之言,不辞辛苦,希望能带给你点滴的收获. 本场 Chat 您将学到如下内容: Java 初识 设计原则及模式 Spring ...
  • 后端技术杂谈 What、How、Why 首页 归档 分类 关于我 谈谈互联网后端基础设施 Aug 27th, 2016 Posted by 飒然Hang in work 本文更新于2016.12.12, 加入了扩展章节 对于一个...
  • FEBS项目搭建后端技术简介所用技术Spring-BootSpring-Boot的特点MyBatis-Plus(数据持久化)Hikari:Mavenredisredis特点shiro 所用技术 最近在学习FEBS开源项目,记录了一下大致的后端所用的技术,及其大致作用 之后...
  • 前端和后端技术介绍

    千次阅读 2018-03-28 10:47:06
    前端技术一般指web前端开发,HTML是网页的结构,CSS是网页的外观,而JavaScript是页面的行为。后端技术主要设计数据库技术,PHP,JSP,ASP.NET等。详情请看http://www.lvyestudy.com/les_hj/hj_1.1.aspx...
  • Java Web 后端技术可视化(一期总结) 1、学习体会 在加入拉钩大数据二期预科班三个月的时间内,从开始刚进入公司以后闲暇的生活变得开始忙忙碌碌起来,中间也由于自身发生了很多事情,也落了一点课程,现在也开始...
  • 众所周知,后端技术包罗万象纷繁复杂,并不是简单学习一门编程语言就可以。随着用户的增长、平台架构的升级,分布式、高性能、高并发、缓存、海量数据、算法、各种框架都源源不断涌现在各位程序员面前,后端技术栈...
  • java后端技术栈路线图

    2020-09-29 17:09:28
    java后端技术栈路线图 很多人做Java开发2,3年后,都会感觉自己遇到瓶颈。什么都会又什么都不会,如何改变困境,为什么很多人写了7,8年还是一个码农,工作中太多被动是因为不懂底层原理。公司的工作节奏又比较快,难...
  • 分布式缓存的一起问题 – 后端技术 by Tim Yang 分布式缓存的一起问题 – 后端技术 by Tim Yang posted on 2015-09-04...
  • 后端技术

    2020-09-14 15:09:27
    说到后端开发,难免会遇到各种所谓高大上的「关键词」,对于我们应届生小白,难免会觉得比较陌生,因为在学校确实比较少遇见这些所谓高大上的东西,那么今天就带着学习的态度和大家分享这些看似可以装逼可以飞的带...
  • 2013-ADC-阿里技术嘉年华PPT下载-aDev-业务架构&后端技术 11 个ppt,包含所有业务架构&后端技术 对外公开的PPT

空空如也

1 2 3 4 5 ... 20
收藏数 19,721
精华内容 7,888
关键字:

后端技术