能力说明:
精通JVM运行机制,包括类生命、内存模型、垃圾回收及JVM常见参数;能够熟练使用Runnable接口创建线程和使用ExecutorService并发执行任务、识别潜在的死锁线程问题;能够使用Synchronized关键字和atomic包控制线程的执行顺序,使用并行Fork/Join框架;能过开发使用原始版本函数式接口的代码。
暂时未有相关云产品技术能力~
公众号:知了一笑
Object类是所有类层级关系的Root节点,作为所有类的超类,包括数组也实现了该类的方法。
泛型即可以理解为把数据类型作为参数,即参数化类型,用来提高代码的安全性,灵活性,避免类型转换。
进程是计算机中的程序,关于某数据集合上的一次运行活动,是系统进行资源分配和调度的基本单位,是操作系统结构的基础。
Cookie在HTTP中通常是用来辨别用户身份,进行会话跟踪而储存在用户本地终端上的数据,一般会加密处理,由用户客户端计算机暂时或永久保存的信息。
HTTP超文本传输协议,是用于从万维网服务器传输超文本到本地浏览器的传送协议,基于TCP/IP通信协议来传递数据:HTML文件、图片、查询数据等。
JVM执行引擎的作用就是将字节码指令解释或者编译为对应平台上的本地机器指令。简单来说,执行引擎充当了将高级语言翻译为机器语言的翻译者。
内存是计算机的重要部件之一,它是外存与CPU进行沟通的桥梁,计算机中所有程序的运行都在内存中进行,内存性能的强弱影响计算机整体发挥的水平。
类的加载机制是指把编译后的.class类文件的二进制数据读取到内存中,并为之创建一个java.lang.Class对象,用来封装类在元数据空间的数据结构。
虚拟机(Virtual Machine)指通过软件模拟的具有完整硬件系统功能的、运行在一个完全隔离环境中的完整计算机系统。
在开发的过程中会遇到各种各样的开发问题,服务器宕机、网络抖动、代码本身的bug等等。针对代码的bug,我们可以提前预支,通过发送告警信息来警示我们去干预,尽早处理。
将版本的分支号加载到服务的元数据信息中,再结合服务名称或者IP地址,来实现对服务列表的多维度过滤,可以支撑大部分轻量级灰度策略的实现。
微服务架构中,网关服务通常提供动态路由,以及流量控制与请求识别等核心能力,保证系统的安全与稳定。
在字典服务中提供的枚举值,根本目的是为了确保数据值的统一性,尽可能的避免同一个信息用两种方式描述。
通常对于Stream的中间操作,可以视为是源的查询,并且是懒惰式的设计,对于源数据进行的计算只有在需要时才会被执行,与数据库中视图的原理相似。
IO技术在JDK中算是极其复杂的模块,其复杂的一个关键原因就是IO操作和系统内核的关联性,另外网络编程,文件管理都依赖IO技术,而且都是编程的难点。
集合体系的源码中,Map中的HashMap的设计堪称最经典,涉及数据结构、编程思想、哈希计算等等,在日常开发中对于一些源码的思想进行参考借鉴还是很有必要的。
List集合体系应该是日常开发中最常用的API,而且通常是作为面试压轴问题(JVM、集合、并发),集合这块代码的整体设计也是融合很多编程思想,对于程序员来说具有很高的参考和借鉴价值。
可以根据各个业务的需要,参考流水线组件的功能文档,不断引入更好的方式去优化流程,最终会形成一个持续交付的自动流程,并且不会对代码层面带来改造成本。
Kubernetes简称K8S,是一个开源的分布式的容器编排引擎,用来对容器化应用进行自动化部署和管理,让部署容器化的应用简单并且高效,支持自动化部署、大规模可伸缩、应用容器化管理。
通过Pipeline流水线的方式,将服务镜像构建编排成一键触发执行,实现自动化的管理流程,是微服务架构中的必要的功能模块。
Docker作为开源的应用容器引擎,可以把应用程序和其相关依赖打包生成一个Image镜像文件,是一个标准的运行环境,提供可持续交付的能力。
围绕持续集成:Jenkins+Docker+K8S相关组件,实现自动化管理源码编译、打包、镜像构建、部署等操作;本篇文章主要描述Pipeline流水线用法。
围绕持续集成:Jenkins+Docker+K8S相关组件,实现自动化管理源码编译、打包、镜像构建、部署等操作;
客户数据平台通过采集多方客户数据(主体与线索)等,从而进行精准的客户分析和人群细分,进而实现高效的客户维系和发掘以及日常营销运营。
元数据(Metadata)即描述数据的数据,但是在实际使用的时候,还是存在很多细分的概念,从本质上看元数据,介于系统和业务中间,提供双方都能明白的语义和逻辑,可以更加高效的支撑数据的业务价值。
当随着业务发展,数据的沉淀越来越多,使用的难度就会陡增,会导致在数据分析之前,需要大量时间去清洗数据。
在系统开发初期,很容易出现这样一种情况:不同业务线上开发人员,因为技术栈和版本时间的影响,在选型的时候会优先使用自己熟悉的,例如MQ中间件常用的:Kafka、Rocket、Rabbit等,这样很容易忽略各个项目之间的组件差异问题;
基于业务场景做好服务的划分和设计,以及公共服务的基础构建,确保业务层的架构合理且可扩展,是否合理的基本考量就是,不断的新增业务场景是否需要做系统的大刀阔斧的改版,如果服务能力不断丰富,系统的改造成本很小,自然架构合理。
用户身份的全局统一标识至关重要,用户实体在不同业务线所产生的行为数据,通过唯一序列号进行识别,这样进行用户分析时看到的画像比较全面;
消息通知的流程设计,在各个业务线中通过消息中心提供的接口方法,将不同场景下的消息内容提交到消息中心,消息中心进行统一维护管理,并根据消息的来源和去向,适配相应的推送逻辑。
通常在业务体系中,都会或多或少的涉及到支付相关的功能;对于一些经验欠缺同学来说,最紧张的就是面对这类支付结算的逻辑,因为流程中的任何细节问题,都可能引发对账异常的情况;
做这些业务设计时,核心思想是:把常用的逻辑进行封装,流程设计为可配置,这样即可在一定时间内应对业务的需求和变化,降低开发成本的支出,从而使研发更侧重核心业务的管理和抽象封装等内容。
在系统开发的过程中,必然存在耗时极高的动作,是基于请求响应模式无法解决的问题,通常会采用解耦的思维,并基于异步或者事件驱动的方式去调度整个流程的完整执行。
采用合理的策略去管理资源的权限并不是一件简单的事,通常随着业务和系统的不断扩展,对权限体系都会带来直接的影响,所以在做结构设计时,需要相对复杂但又要避免过度复杂。
在微服务的代码工程中,配置管理是一项复杂的事情,即需要做好各个环境的配置隔离措施,还需要确保生产环境的配置安全;如果划分的微服务足够的多,还要考虑配置更新时的效率;
阅读源码最重要的是耐着心情慢慢看,并随手画下核心流程,实际上如果有一定的编程经验,不管是阅读什么工程的源码,只要用心去分析单点的实现原理,都算不上过度复杂。
在项目研发的过程中,对于数据存储能力的依赖无处不在,项目初期,相比系统层面的组件选型与框架设计,由于数据体量不大,在存储管理方面通常容易被轻视,当项目发展进入到中后期阶段,系统的复杂性很大程度来源于数据层面;
如果软件系统存在持续的迭代周期,那么其中业务、技术、架构的复杂性都会直线拉升,其相应的开发难度也会提高,随之而来的压力会持续在开发和测试之间来回横跳。
HiKariCP作为SpringBoot2框架的默认连接池,号称是跑的最快的连接池,数据库连接池与之前两篇提到的线程池和对象池,从设计的原理上都是基于池化思想,只是在实现方式上有各自的特点;
本文从对象池的一个简单案例切入,主要分析common-pool2组件关于:池、工厂、配置、对象管理几个角色的源码逻辑,并且参考其在Redis中的实践。
线程池中维护多个线程,当收到调度任务时可以避免创建线程直接执行,并以此降低服务资源的消耗,把相对不确定的并发任务管理在相对确定的线程池中,提高系统服务的稳定性。
微服务工程的架构是一项复杂和持续的过程,其中涉及到的组件也十分繁杂,本文只是选取Gateway、Nacos、Feign三个基础组件做简单的总结,在其逻辑的理解上需要围绕该组件的核心功能和项目使用的API作为切入点,时常查阅源码和官方文档。
好记性不如好Log。项目中日志的管理是基础功能之一,不同的用户和场景下对日志都有特定的需求,从而需要用不同的策略进行日志采集和管理,如果是在分布式的项目中,日志的体系设计更加复杂。
很多技术栈或者开源组件的不断发展,都是为了可以更好的解决场景问题,这就需要开发人员定期关注技术的发展趋势,具备技术视野和洞察能力。
二次封装的方式,可以严格的控制技术栈的迭代扩展,以及版本冲突的问题,通过对二次封装层的统一升级,可以快速实现业务服务的升级,解决不同服务的依赖差异问题。较大程度的降低业务与技术的耦合,如此可以独立的升级技术栈,扩展功能而不影响业务服务的迭代。