转载

【JAVA进阶架构师指南】之一：如何进行架构设计

前言

本博客是长篇系列博客,旨在帮助想提升自己,突破技术瓶颈,但又苦于不知道如何进行系统学习从而提升自己的童鞋.笔者假设读者具有3-5年开发经验,java基础扎实,想突破自己的技术瓶颈,成为一位优秀的架构师,所谓java基础扎实,比如:

1.java语言三大特性.

2.java语言八大基本类型及其表示范围.

3.为什么float和double存在精度丢失?

4.publish/private/default/protected表示的范围?

5.static/final的用法及含义.

一位Java基础扎实的童鞋,以上问题应该都能答上来,并且能知其然知其所以然,从底层原理明白为什么是这样的,在具备这些基础后,才能进阶突破自己,成为更优秀的工程师.

当然,本系列文章为笔者原创,许多观点都是笔者自己的观点,假如有不正确或者想和笔者讨论的,欢迎至极,毕竟每个人都会犯错,大家一起进步岂不妙哉!

如何成为一名架构师?

笔者认为,想成为一名架构师,首先第一点必然是你的技术足够优秀,知识的深度和广度足够,遇到问题能很快从脑海中寻找出最合适的解决之道.其次,架构师会从整体上领导项目,与人打交道必不可少,因此与人沟通这些软技能也必不可少,当然,这个因人而异,有些人天生更会与人打交道,但无论如何,技术足够优秀是基本条件.当然,想成为一名优秀的架构师,实际开发经验是必不可少的,没有多年架构师的经验也不行,但至少,我们想成为一名架构师,理论知识得先掌握不是吗?否则谈何实践呢?因此,我总结了一张JAVA架构师进阶学习图谱:

当然还有许多技术和技能也是需要的,比如:架构师要进行文档输出,会需要画相关的图,常见的比如:流程图/用例图/时序图/泳道图/状态图/协作图等等(回忆一下这些课程在大学的时候是不是老师都讲过?只是我们当时不在意罢了,至少笔者是这样的,哈哈~).再比如java反射机制及其相关API,高性能NIO---Netty框架等等.如果是大数据相关还需要我们了解flink/blink/spark/hadoop/hbase,不一定全都要会,但是至少脑子里面要有个概念,这个技术是干嘛用的,以至于别人说的时候能听得懂.至于为什么没有画在上面的图中,是因为笔者后续的文章只准备写图中的内容,其余的留给童鞋们自己去学习吧.当然,因为博客篇幅所限,每种技术不可能百分百把所有知识点都讲到,但是保证讲的全部都是干货,能让读完的童鞋有所收获!

架构师应该关注什么?

这个问题,换句话说,是我们在进行架构设计的时候应该关注什么,笔者认为从大的层面来讲分两类,功能性需求以及非功能性需求,细分的话有以下六个方面:

1.功能

记得我的老师曾说过,功能是0,其余的是1,再牛逼的架构师,如果不满足功能,再牛逼的设计也是没用的,只有在满足功能的前提下,其他的设计才有用.

2.性能

对现代系统来说,响应时间越短就越可能留住用户,毕竟谁会忍受打开一个页面要等待10秒甚至几分钟呢?至少笔者在访问任何网站的时候,一个网页加载5秒以上就直接关了.常用的性能指标有QPS(每秒查询速率)/TPS(每秒事务处理率).当然,性能需要在系统开发完成后进行预发环境(和生产环境一样的环境)测试,常用的性能测试工具有apachebench(简称ab)/http_load/jmeter等等.QPS也遵循28原则,一天中80%的访问量集中在20%的时间内,可以据此估算网站的QPS,从而规划服务器配置,如果性能不达标,则需要优化,常见的优化手段有加机器(简单粗暴),前端优化(CDN/动静分离/减少请求次数/),后端代码优化,缓存(如redis),JVM优化.

3.可用性

可用性是对现代分布式系统来说,当其子系统有一个或几个节点宕机的时候,是否还能继续提供正常的服务.常用的手段是集群以及自动故障转移,几乎所有分布式系统中使用的技术都支持高可用,比如缓存redis官方提供redis-cluster集群,MongoDB分片集群,消息中间件(ActiveMQ/RabbitMQ/kafka/RocketMQ)集群,数据库MySQL集群等等,如果对以上全部都了解的童鞋,总结一下,会发现它们的核心思想都一样,通过集群提供数据冗余,再通过自动发现并且故障转移机制保证组件的高可用.

4.伸缩性

伸缩性是指当系统容量不够或者多余的时候,是否能方便的进行扩容/缩容处理,很多大公司这方面都做的很好,比较好的策略是容器化,使用docker+k8s进行部署管理,可以方便的进行扩容或者缩容处理,能更好的合理利用资源.

5.扩展性

扩展性是指当有需求发生变更或者新增的时候,是否能在不改代码或者改动很少代码的情况下就能实现功能.扩展性相当考验一个架构师的功力,笔者看来,想设计一个扩展性很好的系统,除了事先考虑,在合适的情景下使用设计模式也是相当好的方案,因此对架构师而言,设计模式很重要!举个例子,有一个上传服务,使用FTP协议进行上传,我们基于apach ftpClient封装了一套接口,此时另外有一个需求,是需要使用SFTP协议,我们又使用jsch封装了另一套接口,那假如后续又有新的协议呢?每新增一个协议就需要我们新增代码来适配,这个时候使用适配器模式是不是就能很好的解决问题呢?这也符合设计模式的思想,面向接口编程,以后新增一个协议,我们只需要新增一个实现类,而不会改动原有代码,是不是在代码改动最少的情况下满足了需求呢?