数据结构+算法=程序

数据是一切能输入到计算机的信息总和,结构是指数据之间的关系,数据结构就是将数据及其之间的关系有效地存储在计算机中。

算法是指对特定问题求解步骤的一种描述,说白了就是解决问题的方法策略

总而言之:数据结构+算法=程序


语言掌握

任何一门开发语言都自己的语法,也有对应开发语言对应的开发框架和开发工具,掌握一门开发语言后,后期再学别的开发语言就要容易很多。

BAT架构师所具备的完整Java技术知识图谱
BAT架构师所具备的完整Java技术知识图谱

线程间的状态转换:

1. 新建(new):新创建了一个线程对象。

2. 可运行(runnable):线程对象创建后,其他线程(比如main线程)调用了该对象的start()方法。该状态的线程位于可运行线程池中,等待被线程调度选中,获取cpu 的使用权 。

3. 运行(running):可运行状态(runnable)的线程获得了cpu 时间片(timeslice) ,执行程序代码。

4. 阻塞(block):阻塞状态是指线程因为某种原因放弃了cpu 使用权,也即让出了cpu timeslice,暂时停止运行。直到线程进入可运行(runnable)状态,才有机会再次获得cpu timeslice 转到运行(running)状态。阻塞的情况分三种:

(一). 等待阻塞:运行(running)的线程执行o.wait()方法,JVM会把该线程放入等待队列(waitting queue)中。

(二). 同步阻塞:运行(running)的线程在获取对象的同步锁时,若该同步锁被别的线程占用,则JVM会把该线程放入锁池(lock pool)中。

(三). 其他阻塞:运行(running)的线程执行Thread.sleep(long ms)或t.join()方法,或者发出了I/O请求时,JVM会把该线程置为阻塞状态。当sleep()状态超时、join()等待线程终止或者超时、或者I/O处理完毕时,线程重新转入可运行(runnable)状态。

5. 死亡(dead):线程run()、main() 方法执行结束,或者因异常退出了run()方法,则该线程结束生命周期。死亡的线程不可再次复生。

BAT架构师所具备的完整Java技术知识图谱

网络OSI七层模型:

著名的开放系统互联基本参考模型,即OSI,是由国际标准化组织(ISO)提出。

OSI的体系结构定义了一个七层模型,用以进行进程间的通讯,并作为一个框架来协调各层标准的指定。

OSI采用七层模型可以带来如下好处:

1)各层之间是独立的。某一层并不需要知道他的下一层是如何实现,仅需要知道该层的接口所提供的服务。

2)灵活性好。当任何一层发生变化时(如技术的变化),只要曾间接口关系不变,则在这层以上或以下各层均不受影响。

3)结构上可分割。各层都可以采用最合适的技术来实现。

4)易于实现和维护。因为整个系统已被分解为若干个相对独立的子系统。

5)能促进标准化工作,因为每一层的功能及其所提供的服务都已有了精确的说明。

BAT架构师所具备的完整Java技术知识图谱

阿里巴巴常用开源框架

由于阿里的高并发访问,已经建立了非常完善的架构基础设施,比如小文件存储:tfs,Dubbo阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和 Spring框架无缝集成,还有内部经常使用到的分布式缓存框架:tair

BAT架构师所具备的完整Java技术知识图谱

熟练掌握常用设计模式

设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的;设计模式使代码编制真正工程化;设计模式是软件工程的基石脉络,如同大厦的结构一样。

BAT架构师所具备的完整Java技术知识图谱

JVM实现机制,垃圾回收算法

JVM基本是BAT面试题目必考,以及重点考察的重点,我举几个例子:

1. 内存模型以及分区,需要详细到每个区放什么。

2. 堆里面的分区:Eden,survivalfrom to,老年代,各自的特点。

1).JVM中堆空间可以分成三个大区,新生代、老年代、永久代

2)新生代可以划分为三个区,Eden区,两个幸存区

3.对象创建方法,对象的内存分配,对象的访问定位。

4.GC收集器有哪些?CMS收集器与G1收集器的特点。

5.Minor GC与Full GC分别在什么时候发生?

6.常见的垃圾回收算法等等。

BAT架构师所具备的完整Java技术知识图谱

WEB开发

很多后端工程师,比如:java web开发工程师,是需要掌握很前段的开发基础:h5、js常用框架:jquery、css以及常见的前段调试开发工具,例如:firebug 、ietester、yslow等等。

也会涉及到很多servlet的访问周期、tomcat、spring等的启动完整过程。

还有很多常用的模版引擎,阿里内部就使用veloctiy,很多公司也还在使用jsp等传统的模版引擎等。

BAT架构师所具备的完整Java技术知识图谱

数据库设计

常见的数据库设计原则

SQL和NOSQL的选型使用,SQL的常规掌握,索引的建立和优化原则等,也会涉及到更多大数据的分库分表原则等。

BAT架构师所具备的完整Java技术知识图谱

开发框架和中间件框架选择

java领域使用到的开源框架可供选项范围很多,目前常用的web开发框架组合,典型的就是SSM(springMVC+Spring+Mybatis)

中间件的框架选择也比较多,例如:分布式缓存这块就有memcached,redis等。还有常见的消息队列框架:ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ。

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题,目前使用最多的是ActiveMQ和Kafka。

这里也会涉及到分布式小文件的存储等。

BAT架构师所具备的完整Java技术知识图谱

常用的开发工具

BAT架构师所具备的完整Java技术知识图谱

架构设计经验

架构设计更多来自于大型网站的架构设计变迁,需要积累完整的数据库、设计模式、中间件选择、数据库性能优化、负载均衡、微服务架构的掌握等:

BAT架构师所具备的完整Java技术知识图谱

大型网站架构设计场景

BAT架构师所具备的完整Java技术知识图谱
BAT架构师所具备的完整Java技术知识图谱

一、消息队列

一个大型的分布式系统,通常都会异步化,走消息总线。 消息队列作为最主要的基础组件,在整个体系架构中,有着及其重要的作用。kafka是目前最常用的消息队列,尤其是在大数据方面,有着极高的吞吐量。而rocketmq和rabbitmq,都是电信级别的消息队列,在业务上用的比较多。2019年了,不要再盯着JMS不放了(说的就是臃肿的ActiveMQ)。

pulsar是为了解决一些kafka上的问题而诞生的消息系统,比较年轻,工具链有限。有些激进的团队经过试用,反响不错。

mqtt具体来说是一种协议,主要用在物联网方面,能够双向通信,属于消息队列范畴。

二、缓存

数据缓存是减少数据库压力的有效途径,有单机java内缓存,和分布式缓存之分。

对于单机来说,guava的cache和ehcache都是些熟面孔。

对于分布式缓存来说,优先选择的就是redis,别犹豫。由于redis是单线程的,并不适合高耗时操作。所以对于一些数据量比较大的缓存,比如图片、视频等,使用老牌的memcached效果会好的多。

JetCache是一个基于Java的缓存系统封装,提供统一的api和注解来简化缓存的使用。类似SpringCache,支持本地缓存和分布式缓存,是简化开发的利器。

三、分库分表

分库分表,几乎每一个上点规模的公司,都会有自己的方案。目前,推荐使用驱动层的sharding-jdbc,或者代理层的mycat。如果你没有额外的运维团队,又不想花钱买其他机器,那么就选前者。

如果分库分表涉及的项目不多,spring的动态数据源是一个非常好的选择。它直接编码在代码里,直观但不易扩展。

如果只需要读写分离 ,那么mysql官方驱动里的replication协议,是更加轻量级的选择。

上面的分库分表组件,都是大浪淘沙,最终的优胜品。这些组件不同于其他组件选型,方案一旦确定,几乎无法回退,所以要慎之又慎。

分库分表是小case,准备分库分表的阶段,才是重点:也就是数据同步。

四、数据同步

国内使用mysql的公司居多,但postgresql凭借其优异的性能,使用率逐渐攀升。

不管什么数据库,实时数据同步工具,都是把自己模拟成一个从库,进行数据拉取和解析。具体来说,mysql是通过binlog进行同步;postgresql使用wal日志进行同步。

对mysql来说,canal是国内用的最多的方案;类似的databus也是比较好用的工具。

现在,canal、maxwell等工具,都支持将要同步的数据写入到mq中,进行后续处理,方便了很多。

对于ETL(抽取、清洗、转换)来说,基本上都是source、task、sink路线,与前面的功能对应。gobblin、datax、logstash、sqoop等,都是这样的工具。

它们的主要工作,就是怎么方便的定义配置文件,编写各种各样的数据源适配接口等。这些ETL工具,也可以作为数据同步(尤其是全量同步)的工具,通常是根据ID,或者最后更新时间 等,进行处理。

binlog是实时增量工具,ETL工具做辅助。通常一个数据同步功能,需要多个组件的参与,他们共同组成一个整体。

五、通讯

Java 中,netty已经成为当之无愧的网络开发框架,包括其上的socketio(不要再和我提mina了)。对于http协议,有common-httpclient,以及更加轻量级的工具okhttp来支持。

对于一个rpc来说,要约定一个通讯方式和序列化方式。json是最常用的序列化方式,但是传输和解析成本大,xml等文本协议与其类似,都有很多冗余的信息;avro和kryo是二进制的序列化工具,没有这些缺点,但调试不便。

rpc是远程过程调用的意思 ,其中,thrift、dubbo、gRPC默认都是二进制序列化方式的socket通讯框架;feign、hessian都是onhttp的远程调用框架。

对了,gRPC的序列化工具是protobuf,一个压缩比很高的二进制序列化工具。

通常,服务的响应时间主要耗费在业务逻辑以及数据库上,通讯层耗时在其中的占比很小。可以根据自己公司的研发水平和业务规模来选择。

六、微服务

我们不止一次说到微服务,这一次我们从围绕它的一堆支持框架,来窥探一下这个体系。是的,这里依然是在说spring cloud。

默认的注册中心eureka不再维护,consul已经成为首选。nacos、zookeeper等,都可以作为备选方案。其中nacos带有后台,比较适合国人使用习惯。

熔断组件,官方的hystrix也已经不维护了。推荐使用resilience4j,最近阿里的sentinel也表现强劲。

对于调用链来说,由于OpenTracing的兴起,有了很多新的面孔。推荐使用jaeger或者skywalking。spring cloud集成的sleuth+zipkin功能稍弱,甚至不如传统侵入式的cat。

配置中心是管理多环境配置文件的利器,尤其在你不想重启服务器的情况下进行配置更新。目前,开源中做的最好的要数apollo,并提供了对spring boot的支持。disconf使用也较为广泛。相对来说,spring cloud config功能就局限了些,用的很少。


网关方面,使用最多的就是nginx,在nginx之上,有基于lua脚本的openrestry。由于openresty的使用非常繁杂,所以有了kong这种封装级别更高的网关。

对于spring cloud来说,zuul系列推荐使用zuul2,zuul1是多线程阻塞的,有硬伤。spring-cloud-gateway是spring cloud亲生的,但目前用的不是很广泛。

七、分布式工具

大家都知道分布式系统zookeeper能用在很多场景,与其类似的还有基于raft协议的etcd和consul。

由于它们能够保证极高的一致性,所以用作协调工具是再好不过了。用途集中在:配置中心、分布式锁、命名服务、分布式协调、master选举等场所。

对于分布式事务方面,则有阿里的fescar工具进行支持。但如非特别的必要,还是使用柔性事务,追寻最终一致性,比较好。

八、监控系统

监控系统组件种类繁多,目前,最流行的大概就是上面四类。

zabbix在主机数量不多的情况下,是非常好的选择。

prometheus来势凶猛,大有一统天下的架势。它也可以使用更加漂亮的grafana进行前端展示。

influxdata的influxdb和telegraf组件,都比较好用,主要是功能很全。

使用es存储的elkb工具链,也是一个较好的选择。我所知道的很多公司,都在用。

九、调度

大家可能都用过cron表达式。这个表达式,最初就是来自linux的crontab工具。

quartz是java中比较古老的调度方案,分布式调度采用数据库锁的方式,管理界面需要自行开发。

elastic-job-cloud应用比较广泛,但系统运维复杂,学习成本较高。相对来说,xxl-job就更加轻量级一些。中国人开发的系统,后台都比较漂亮。

十、入口工具

为了统一用户的访问路口,一般会使用一些入口工具进行支持。

其中,haproxy、lvs、keepalived等,使用非常广泛。

服务器一般采用稳定性较好的centos,并配备ansible工具进行支持,那叫一个爽。

十一、OLT(A)P

现在的企业,数据量都非常大,数据仓库是必须的。

搜索方面,solr和elasticsearch比较流行,它们都是基于lucene的。solr比较成熟,稳定性更好一些,但实时搜索方面不如es。

列式存储方面,基于Hadoop 的hbase,使用最是广泛;基于LSM的leveldb写入性能优越,但目前主要是作为嵌入式引擎使用多一些。

tidb是国产新贵,兼容mysql协议,公司通过培训向外输出dba,未来可期。

时序数据库方面,opentsdb用在超大型监控系统多一些。druid和kudu,在处理多维度数据实时聚合方面,更胜一筹。

cassandra在刚出现时火了一段时间,虽然有facebook弃用的新闻,但生态已经形成,常年霸占数据库引擎前15名。

十二、CI/CD

为了支持持续集成和虚拟化,除了耳熟能详的docker,我们还有其他工具。

jenkins是打包发布的首选,毕竟这么多年了,一直是老大哥。当然,写Idea的那家公司,还出了一个叫TeamCity的工具,操作界面非常流畅。

sonar(注意图上的错误)不得不说是一个神器,用了它之后,小伙伴们的代码一片飘红,我都快被吐沫星子给淹没了。

对于公司内部来说,一般使用gitlab搭建git服务器。其实,它里面的gitlab CI,也是非常好用的。

十三、问题排查

java经常发生内存溢出问题。使用jmap导出堆栈后,我一般使用mat进行深入分析。

如果在线上实时分析,有arthas和perf两款工具。

当然,有大批量的linux工具进行支持。比如下面这些:

《Linux上,最常用的一批命令解析(10年精选)》

十四、本地工具

本地使用的jar包和工具,那就多了去了。下面仅仅提一下最最常用的几个。

数据库连接池方面,国内使用druid最多。目前,有号称速度最快的hikari数据库连接池,以及老掉牙的dbcp和c3p0。

json方面,国内使用fastjson最多,三天两头冒出个漏洞;国外则使用jackson多一些。它们的api都类似,jackson特性多一些,但fastjson更加容易使用。

工具包方面,虽然有各种commons包,guava首选。