大家好,又见面了,我是你们的朋友全栈君。
使用Java后端技术的目的就是构建业务应用,为用户提供在线或者离线服务。因此,一个业务应用需要哪些技术、依赖哪些基础设施就决定了需要掌握的后端技术有哪些。纵观整个互联网技术体系再结合公司的目前状况,笔者认为必不可少或者非常关键的后端基础技术/设施如下图所示:
这里的后端基础设施主要指的是应用在线上稳定运行需要依赖的关键组件或者服务。开发或者搭建好以上的后端基础设施,一般情况下是能够支撑很长一段时间内的业务的。此外,对于一个完整的架构来说,还有很多应用感知不到的系统基础服务,如负载均衡、自动化部署、系统安全等,并没有包含在本章的描述范围内。
在移动APP的开发过程中,通常后端提供的接口需要以下功能的支持:
• 负载均衡 • API访问权限控制 • 用户鉴权
一般的做法,使用Nginx做负载均衡,然后在每个业务应用里做API接口的访问权限控制和用户鉴权,更优化一点的方式则是把后两者做成公共类库供所有业务调用。但从总体上来看,这三种特性都属于业务的公共需求,更可取的方式则是集成到一起作为一个服务,既可以动态地修改权限控制和鉴权机制,也可以减少每个业务集成这些机制的成本。这种服务就是API网关,可以选择自己实现。也可以使用开源软件实现,如Kong和Netflix Zuul。API网关一般架构如下图所示:
但是以上方案的一个问题是由于所有API请求都要经过网关,它很容易成为系统的性能瓶颈。因此,可以采取的方案是:去掉API网关,让业务应用直接对接统一认证中心,在基础框架层面保证每个API调用都需要先通过统一认证中心的认证,这里可以采取缓存认证结果的方式避免对统一认证中心产生过大的请求压力。
业务应用分为:在线业务应用和内部业务应用。
一般来说,以上几个框架即可以完成一个后端应用的雏形。
缓存、数据库、搜索引擎、消息队列这四者都是应用依赖的后端基础服务,他们的性能直接影响到了应用的整体性能,有时候你代码写的再好也许就是因为这些服务导致应用性能无法提升上去。
不管是业务应用、依赖的后端服务还是其他的各种服务,最终还是要依赖于底层文件存储的。通常来说,文件存储需要满足的特性有:可靠性、容灾性、稳定性,即要保证存储的数据不会轻易丢失,即使发生故障也能够有回滚方案,也要保证高可用。在底层可以采用传统的RAID作为解决方案,再上一层,目前Hadoop的HDFS则是最为普遍的分布式文件存储方案,当然还有NFS、Samba这种共享文件系统也提供了简单的分布式存储的特性。
此外,如果文件存储确实成为了应用的瓶颈或者必须提高文件存储的性能从而提升整个系统的性能时,那么最为直接和简单的做法就是抛弃传统机械硬盘,用SSD硬盘替代。像现在很多公司在解决业务性能问题的时候,最终的关键点往往就是SSD。这也是用钱换取时间和人力成本最直接和最有效的方式。在数据库部分描述的SSDB就是对LevelDB封装之后,利用SSD硬盘的特性的一种高性能KV数据库。
至于HDFS,如果要使用上面的数据,是需要通过Hadoop的。类似xx on Yarn的一些技术就是将非Hadoop技术跑在HDFS上的解决方案。
统一认证中心,主要是对APP用户、内部用户、APP等的认证服务,包括:
之所以需要统一认证中心,就是为了能够集中对这些所有APP都会用到的信息进行管理,也给所有应用提供统一的认证服务。尤其是在有很多业务需要共享用户数据的时候,构建一个统一认证中心是非常必要的。此外,通过统一认证中心构建移动APP的单点登录也是水到渠成的事情:模仿Web的机制,将认证后的信息加密存储到本地存储中供多个APP使用。
目前很多大的在线Web网站都是有单点登录系统的,通俗的来说就是只需要一次用户登录,就能够进入多个业务应用(权限可以不相同),非常方便用户的操作。而在移动互联网公司中,内部的各种管理、信息系统甚至外部应用同样也需要单点登录系统。
目前,比较成熟的、用的最多的单点登录系统应该是耶鲁大学开源的CAS
基本上,单点登录的原理都类似下图所示:
在Java后端应用中,一种读写配置比较通用的方式就是将配置文件写在Propeties、YAML、HCON等文件中,修改的时候只需要更新文件重新部署即可,可以做到不牵扯代码层面改动的目的。统一配置中心,则是基于这种方式之上的统一对所有业务或者基础后端服务的相关配置文件进行管理的统一服务, 具有以下特性:
百度开源的Disconf和携程的Apollo是可以在生产环境使用的方案,也可以根据自己的需求开发自己的配置中心,一般选择Zookeeper作为配置存储。
对于外部API调用或者客户端对后端API的访问,可以使用HTTP协议或者RESTful(当然也可以直接通过最原始的socket来调用)。但对于内部服务间的调用,一般都是通过RPC机制来调用的。目前主流的RPC协议有:
这些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可以实现服务的客户端软负载均衡,支持多种灵活的动态路由和负载均衡策略。
在很多业务中,定时调度是一个非常普遍的场景,比如定时去抓取数据、定时刷新订单的状态等。通常的做法就是针对各自的业务依赖Linux的Cron机制或者Java中的Quartz。统一调度中心则是对所有的调度任务进行管理,这样能够统一对调度集群进行调优、扩展、任务管理等。Azkaban和Yahoo的Oozie是Hadoop的流式工作管理引擎,也可以作为统一调度中心来使用。当然,你也可以使用Cron或者Quartz来实现自己的统一调度中心。
对于Java的Quartz这里需要说明一下:这个Quartz需要和Spring Quartz区分,后者是Spring对Quartz框架的简单实现也是目前使用的最多的一种调度方式。但其并没有做高可用集群的支持。而Quartz虽然有集群的支持,但是配置起来非常复杂。现在很多方案都是使用Zookeeper来实现Spring Quartz的分布式集群。
此外,当当网开源的elastic-job则在基础的分布式调度之上又加入了弹性资源利用等更为强大的功能。
日志是开发过程必不可少的东西。打印日志的时机、技巧是很能体现出工程师编码水平的。毕竟,日志是线上服务能够定位、排查异常最为直接的信息。
通常的,将日志分散在各个业务中非常不方便对问题的管理和排查。统一日志服务则使用单独的日志服务器记录日志,各个业务通过统一的日志框架将日志输出到日志服务器上。
可以通过实现Log4j或者Logback的Appender来实现统一日志框架,然后通过RPC调用将日志打印到日志服务器上。
数据是最近几年非常火的一个领域。从《精益数据分析》到《增长黑客》,都是在强调数据的非凡作用。很多公司也都在通过数据推动产品设计、市场运营、研发等。这里需要说明的一点是,只有当你的数据规模真的到了单机无法处理的规模才应该上大数据相关技术,千万不要为了大数据而大数据。很多情况下使用单机程序+MySQL就能解决的问题非得上Hadoop即浪费时间又浪费人力。
这里需要补充一点的是,对于很多公司,尤其是离线业务并没有那么密集的公司,在很多情况下大数据集群的资源是被浪费的。因此诞了 xx on Yarn 一系列技术让非Hadoop系的技术可以利用大数据集群的资源,能够大大提高资源的利用率,如Docker on Yarn。
此外,Logstash也是一个可以选择的日志收集方案,不同于以上的是,它更倾向于数据的预处理,且配置简单、清晰,经常以ELK(Elasticsearch + Logstash + Kibana)的架构用于运维场景中。 • 传输:通过消息队列将数据传输到数据处理服务中。对于日志来说,通常选择Kafka这个消息队列即可。 此外,这里还有一个关键的技术就是数据库和数据仓库间的数据同步问题,即将需要分析的数据从数据库中同步到诸如Hive这种数据仓库时使用的方案。可以使用Apache Sqoop进行基于时间戳的数据同步,此外,阿里开源的Canal实现了基于binlog增量同步,更加适合通用的同步场景,但是基于Canal还是需要做不少的业务开发工作。
其中,Druid相对比较轻量级,用的人较多,比较成熟。
离线和实时数据分析产生的一些报表是给数据分析师、产品经理参考使用的,但是很多情况下,线上的程序并不能满足这些需求方的需求。这时候就需要需求方自己对数据仓库进行查询统计。针对这些需求方,SQL上手容易、易描述等特点决定了其可能是一个最为合适的方式。因此提供一个SQL的即席查询工具能够大大提高数据分析师、产品经理的工作效率。Presto、Impala、Hive都是这种工具。如果想进一步提供给需求方更加直观的ui操作界面,可以搭建内部的Hue。
对于面向用户的线上服务,发生故障是一件很严重的事情。因此,做好线上服务的故障检测告警是一件非常重要的事情。可以将故障监控分为以下两个层面的监控:
监控还有一个关键的步骤就是告警。告警的方式有很多种:邮件、IM、短信等。考虑到故障的重要性不同、告警的合理性、便于定位问题等因素,有以下建议:
名称 | 介绍 |
---|---|
Spring Framework | 基于IOC和AOP的构架多层j2ee系统的框架 |
SpringMVC | MVC框架 |
Spring secutity | Shiro: 安全框架 |
Spring session | 分布式Session管理 |
MyBatis | ORM框架 |
MyBatis Generator | 代码生成 |
Druid | 数据库连接池 |
Jsp、Velocity、Thymeleaf | 模板引擎 |
ZooKeeper | 协调服务 |
Dubbo | 分布式服务框架 |
TBSchedule、elastic-job | 分布式调度框架 |
Redis | 分布式缓存数据库 |
Quartz | 作业调度框架 |
Ehcache | 缓存框架 |
ActiveMQ | 消息队列 |
Solr、Elasticsearch | 分布式全文搜索引擎 |
FastDFS | 分布式文件系统 |
Log4J | 日志管理 |
Swagger2 | 接口文档 |
sequence | 分布式高效ID生产 http://git.oschina.net/yu120/sequence |
AliOSS、Qiniu | 云存储 |
Protobuf、json | 数据传输 |
Jenkins | 持续集成工具 |
Maven、Gradle | 项目构建管理 |
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/106587.html原文链接:https://javaforall.cn