首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    成为java架构师需要具备那些技能?

    大家好,又见面了,我是你们的朋友全栈君。架构师定义 百度百科,系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。 架构师工作职能 软件架构师在整个软件开发过程中都起着重要的作用,并随着开发进程的推进而其职责或关注点不断地变化,在需求阶段,软件架构师主要负责理解和管理非功能性系统需求,比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等等,此外,架构师还要经常审查客户及市场人员所提出的需求,确认开发团队所提出的设计;在需求越来越明确后,架构师的关注点开始转移到组织开发团队成员和开发过程定义上;在软件设计阶段,架构师负责对整个软件体系结构、关键构件、接口和开发政策的设计;在编码阶段,架构师则成为详细设计者和代码编写者的顾问,并且经常性地要举行一些技术研讨会、技术培训班等;随着软件开始测试、集成和交付,集成和测试支持将成为软件架构师的工作重点;在软件维护开始时,软件架构师就开始为下一版本的产品是否应该增加新的功能模块进行决策。 成为java架构师所需要具备那些技能? 所谓架构师,思考的是全局的东西,是如何组织你的系统,以达到业务要求,性能要求,具备可扩展性(scalability),可拓展性(extendability),前后兼容性等。可能涉及到的东西包括了从硬件到软件的方方面面,实在是一言难尽。 既然java架构师,首先你要是一个高级java攻狮城,熟练使用各种框架,并知道它们实现的原理。jvm虚拟机原理、调优,懂得jvm能让你写出性能更好的代码;池技术,什么对象池,连接池,线程池…:;java反射技术,写框架必备的技术,但是有严重的性能问题,替代方案java字节码技术;nio,没什么好说的,值得注意的是”直接内存”的特点,使用场景;java多线程同步异步;java各种集合对象的实现原理,了解这些可以让你在解决问题时选择合适的数据结构,高效的解决问题,比如hashmap的实现原理,好多五年以上经验的人都弄不清楚,还有为什扩容时有性能问题?不弄清楚这些原理,就写不出高效的代码,还会认为自己做的很对;总之一句话越基础的东西越重要,很多人认为自己会用它们写代码了,其实仅仅是知道如何调用api而已,离会用还差的远。 熟练使用各种数据结构和算法,数组、哈希、链表、排序树…,一句话要么是时间换空间要么是空间换时间,这里展开可以说一大堆,需要有一定的应用经验,用于解决各种性能或业务上的问题。 熟练使用linux操作系统,必备,没什么好说的。 熟悉tcp协议,创建连接三次握手和断开连接四次握手的整个过程,不了解的话,无法对高并发网络应用做优化;熟悉http协议,尤其是http头,我发现好多工作五年以上的都弄不清session和cookie的生命周期以及它们之间的关联。 系统集群、负载均衡、反向代理、动静分离,网站静态化。 分布式存储系统nfs,fastdfs,tfs,Hadoop了解他们的优缺点,适用场景。 分布式缓存技术memcached,redis,提高系统性能必备,一句话,把硬盘上的内容放到内存里来提速,顺便提个算法一致性hash。 工具nginx必备技能超级好用,高性能,基本不会挂掉的服务器,功能多多,解决各种问题。 数据库的设计能力,mysql必备,最基础的数据库工具,免费好用,对它基本的参数优化,慢查询日志分析,主从复制的配置,至少要成为半个mysqldba。其他nosql数据库如mongodb。 还有队列中间件。如消息推送,可以先把消息写入数据库,推送放队列服务器上,由推送服务器去队列获取处理,这样就可以将消息放数据库和队列里后直接给用户反馈,推送过程则由推送服务器和队列服务器完成,好处异步处理、缓解服务器压力,解藕系统。 想成为架构师不是懂了一大堆技术就可以了,这些是解决问题的基础、是工具,不懂这些怎么去提解决方案呢?这是成为架构师的必要条件。 架构师还要针对业务特点、系统的性能要求提出能解决问题成本最低的设计方案才合格,人家一个几百人用户的系统,访问量不大,数据量小,你给人家上集群、上分布式存储、上高端服务器,为了架构而架构,这是最扯淡的,架构师的作用就是第一满足业务需求,第二最低的硬件网络成本和技术维护成本。 架构师还要根据业务发展阶段,提前预见发展到下一个阶段系统架构的解决方案,并且设计当前架构时将架构的升级扩展考虑进去,做到易于升级;否则等系统瓶颈来了,出问题了再去出方案,或现有架构无法扩展直接扔掉重做,或扩展麻烦问题一大堆,这会对企业造成损失。

    01

    敏捷团队高效的完成软件架构设计

    在敏捷开发下,如何能经由敏捷团队,高效的完成软件架构设计?核心的思维是:以“团队”为纬度,而不再以“产品”为纬度进行软件架构设计。这种以“团队”为纬度的软件架构方式,将会使所设计的软件架构,因过于复杂与庞大;超过团队所能理解、控制、处理的范围。而使软件架构无法建立起一致性、统一性;某些类(Class)或数据表结构的定义是互相矛盾或相关的规则是互相冲突的。过去团队往往得花上大量的人力与时间成本,才能解决上述由软件架构设计所引入的不一致性、不统一的问题。在敏捷开发中,为有效的提升产品开发的效率与质量,则可借镜 Domain-Driven Design 的思维;以“团队”的纬度,而非以“产品”为纬度进行软件架构设计。每个团队,在 Product Owner 的带领下,只专注在自身团队的“Bounded Context”;确保自身团队的 Bounded Context 内的类与数据表结构的一致性、统一性。而整个产品,则在 Super Product Owner 的带领下,建立起各个团队 Bounded Context 间的关系、关系类型、接口(协议)的定义。最后,整个产品团队,将实际上经由持续集成,使由“团队”为纬度的软件架构,集成为“产品”级软件架构。并得以确保“产品”的软件架构,在持续集成后是拥有一致性与统一性的。

    07
    领券