猿创征文|点亮技术之路的三盏灯

目录

      前言

      第一盏灯:学习&运气

      第二盏灯:技术&信任

      第三盏灯:思维&沟通


      前言

        也许,我是幸运的,可以说几乎每一次的技术储备,都能在关键时刻起到“救命稻草”的作用。

        从一名刚入职的java开发人员,到技术骨干,然后担任技术组长,技术经理,技术总监,每一次跳跃都会带来一次技术视野的提升,技术视野的打开,又会带来下一次的机遇。

      第一盏灯:学习&运气

        工作之初,接触的第一个JDK版本为1.5,先后历经了1.6、1.7、1.8 三个大版本的更迭,当时使用的IDE是Eclipse,集成的tomcat版本也需要跟着调整,也正是在这个过程中, 养成了技术之间横向对比的习惯,包括后来在spring、mysql、activiti、lucene、mq、mongodb进行版本选择时,发挥了重要的作用。

        有时候也会有些额外收获,比如在进行spring版本比对时,无意间会想到spring里会有循环依赖的问题,出于好奇,也会抽一部分时间了解下如何解决。

        创建两个service,在ServiceA中注入ServiceB,在ServiceB中注入ServiceA,这样ServiceA和ServiceB便相互引用,也就形成了循环依赖。

        代码如下:

package com.zhufeng.service;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
 
/**
 * @author 月夜烛峰
 */
@Service
public class ServiceA {
    @Autowired
    private ServiceB serviceB;
}
package com.zhufeng.service;
 
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
 
/**
 * @author 月夜烛峰
 */
@Service
public class ServiceB {
    @Autowired
    private ServiceA serviceA;
}

        实现流程:

         因为事先了解过spring的生命周期,借着这个机会,又可以对spring的refresh()进行更进一步的了解,技术的深度与广度在无意间逐步增强、增进。

	@Override
	public void refresh() throws BeansException, IllegalStateException {
		synchronized (this.startupShutdownMonitor) {
			// Prepare this context for refreshing.
			prepareRefresh();

			// Tell the subclass to refresh the internal bean factory.
			ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

			// Prepare the bean factory for use in this context.
			prepareBeanFactory(beanFactory);

			try {
				// Allows post-processing of the bean factory in context subclasses.
				postProcessBeanFactory(beanFactory);

				// Invoke factory processors registered as beans in the context.
				invokeBeanFactoryPostProcessors(beanFactory);

				// Register bean processors that intercept bean creation.
				registerBeanPostProcessors(beanFactory);

				// Initialize message source for this context.
				initMessageSource();

				// Initialize event multicaster for this context.
				initApplicationEventMulticaster();

				// Initialize other special beans in specific context subclasses.
				onRefresh();

				// Check for listener beans and register them.
				registerListeners();

				// Instantiate all remaining (non-lazy-init) singletons.
				finishBeanFactoryInitialization(beanFactory);

				// Last step: publish corresponding event.
				finishRefresh();
			}

			catch (BeansException ex) {
				if (logger.isWarnEnabled()) {
					logger.warn("Exception encountered during context initialization - " +
							"cancelling refresh attempt: " + ex);
				}

				// Destroy already created singletons to avoid dangling resources.
				destroyBeans();

				// Reset 'active' flag.
				cancelRefresh(ex);

				// Propagate exception to caller.
				throw ex;
			}

			finally {
				// Reset common introspection caches in Spring's core, since we
				// might not ever need metadata for singleton beans anymore...
				resetCommonCaches();
			}
		}
	}

       谁能想到,在这个加班节奏中等,上下级关系融洽,工作氛围良好的公司,居然会突然决定会进行一次规模较大的架构整合,要求一个月给出架构方案、技术选型、开发周期,三个月进行技术可行性论证评审。

        鉴于我的技术储备及学习能力,毫无疑问的成为了这次项目的技术负责人,从此点亮了技术之路的第一盏灯。

      第二盏灯:技术&信任

        说是试探,其实心里真是没底。

        高并发(500TPS以上)、高可用是刚需,网络安全方面需要考虑网络分区、用户权限分级、流量监控及应对常见的网络攻击;技术架构需要考虑各个技术组件的兼容性、实用性、稳定性,以及底层架构的统一实现;应用架构还有考虑各个应用之间的各种对接规则、发版规则,接口规范等。

        一番分析就一句话:路漫漫其修远兮,吾将上下而求索......

        整个技术团队在一片迷茫中继续前行,没有想到同在“温水”中泡澡的我们,居然在这一刻还能够相互鼓励,曾连续几天都奋斗到凌晨凌两三点,大半夜三点多去“KTV”一顿狼嚎之后,回来继续鸡血。

        之前的技术积累,在这一刻开始了各种爆发,当理论开始落地且能够落地的时候,会很明显的感受到一种向上的升力,情不自禁的拖着自己前行。

        很多底层的技术知识开始弥补,底层基础决定上层架构,各种各样的灵感在高压下不断涌现,每一次沟通、辩论都会有新的东西,更是再一步巩固了先前的技术体系。

        一个月内不仅给出了架构方案,而且是三套,可根据优先级进行筛选,当然也比较顺利的完成了后续的技术架构评审。

        这一次工作完成直接导致了职位的升迁,可以说技术是硬实力,决定了可以争取到这个机会,对技术的态度与坚持,赢得了一批志同道合的朋友同事的认可,有信心继续走下去,这种信任与鼓励又反过来影响了自己,相互影响相互扶持。

        于是,点亮了自己的第二盏灯。

        架构搭建、架构重构、平台搭建这种工作,后面又负责了多次,基于前面的实践与落地,底气十足,尤其是将原有业务应用体系全部采用springcloud技术体系进行架构重构时,更是轻车熟路,迎来了技术之路的新的高度。

      第三盏灯:思维&沟通

        从最开始自己的单打独斗,然后组团攻坚,对技术的掌握、使用、认知都开始发生变化,到最后将技术能力凝练到可以灵活解决业务问题,并对其中的原理、逻辑都能讲的明明白白的时候,也会顺带不断打破职业瓶颈,继续提升。

        近期围绕IO举行了一次技术沙龙,围绕各种IO流的快慢进行讨论,也谈到了kafka使用NIO的各种优势,但是大家各执一词,讨论很僵持,究竟哪种IO好用,没有得出让大家认同的结果,这个时候的思维方式,很容易体现出技术掌握能力;沟通表达能力,又能体现对技术的理解能力。

        于在以下环境我们开始了一波实际的测试

环境准备:在Mac中创建Linux虚拟机
系统版本:centos7.9(aarch64)

处理器:    4核
系统内存:8G
磁盘大小:128G

        凡是参与讨论的IO我们都加入进行对比,总共五个,以读取1G文件测试为主进行测试。缓冲字节从32字节开始,递增至 8M进行对比,结果图如下:

        数据信息:

        数据分析:

        从读取的数据信息中可以看到,在缓存字节4K之前,MappedByteBuffer占据优势,字节数越少优势越明显,缓冲字节在4K之后,不分伯仲。

        注意:

        bufferedInputStream默认有8K缓冲字节,可认为整个测试过程中,虽然效率上MappedByteBuffer不分伯仲,缓冲字节都为8K,因此不具备可比性。

        经过这样一番效果认证,后续又通过监控磁盘IO、系统缓存、虚拟内存等一系列的数据监控,用数据说明了各个IO在各种条件下的运行效果,最后达成了一致。

        继续成长,在技术这条路上继续努力,或者说也是架构师这条路,就是如今的第三盏灯,本质上就是一种解决问题的能力,不在局限于某一具体的技术,开始在行业内继续充电了解技术更迭,也在技术团队中授人以渔提高整体技术能力。

        一路走来,自己是幸运的,遇到了很多机遇,在很多时候也做了很好的选择,也庆幸自己在学习的过程中很好的做了一些积累,在关键时候不至于囊中羞涩。

        技术之路,曲曲折折,做好选择,放手努力,等一个机会,前面躺过的坑,其实也可以帮助填平后面的路。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码

)">
< <上一篇
下一篇>>