网站开发硬件设计,课程网站建设的步骤,网站论坛建设需要什么资质,息壤网站打不开了来源#xff1a;阿里云 作者#xff1a;林昊#xff08;花名毕玄#xff09;#xff0c;阿里巴巴技术保障部研究员#xff0c;曾任淘宝网平台架构部架构师。个人的研究方向主要为Java模块化、动态化系统的构建#xff0c;以及高性能大型分布式Java系统构建#xff0c;主… 来源阿里云 作者林昊花名毕玄阿里巴巴技术保障部研究员曾任淘宝网平台架构部架构师。个人的研究方向主要为Java模块化、动态化系统的构建以及高性能大型分布式Java系统构建主导阿里数据中心异地多活项目建设。 架构师这个title就和总监之类的title一样已经彻底被用烂了。但在一个软件产品的生命周期中架构师是实实在在的一个极度重要的角色。架构师非常重要的职责是编写整个系统中核心部分的代码。这个部分并不一定是技术挑战最高的但对整个系统的质量甚至成败起到非常关键的控制作用。架构师必须是从写核心代码的人中诞生而来。毕玄的这篇文章就是主要讲他理解的架构师到底应该具备什么素质。 业务理解和抽象能力 架构师的第一职责是理解业务并转换为可被研发理解的实现方案因此业务理解能力是架构师的必备技能。通常来说一个资深的业务架构师对业务会有非常深的认识和积累。一个极好的业务架构师应该能大概预判业务未来的发展趋势以便在系统的可扩展性上留好一定的空间。所以也会很自然的出现有些业务架构师做着做着就干脆转为PD类型的角色。 抽象能力是通过对业务的理解转换为系统实现的模型这显然也是重要的能力。抽象很多时候也承担了分解清楚多个团队的职责分工清晰化。NB的代码能力 之所以现在很多的架构师都会被认为是大忽悠就是有一堆顶着架构师头衔又不干活的人甚至会出现对技术几乎不太懂的人光说不干再加上说的不靠谱的话自然很容易被认为是大忽悠。 我一直认为架构师有个非常重要的职责是编写整个系统中核心部分的代码。这个部分并不一定是技术挑战最高的但对整个系统的质量甚至成败起到非常关键的控制作用。所以架构师必须是从写核心代码的人中诞生而来。在一个跨多领域的大型系统中架构师不太可能什么都擅长不可能写各个部分的核心代码这种时候架构师一定要知道怎么判断非自己知识领域的部分实现是否OK以确保各部分组合在一起的时候是符合架构设计预期的通常这种确保各部分组织在一起work的机制部分的代码应该由架构师自己操刀。 最关键素质全面 全面是一个架构师展现出来的最关键素质全面体现为以下三点 一、在面对业务问题上架构师脑海里是否会浮现出多种技术方案 这点其实挺重要的。否则可能就会出现明明有一个简单成熟的方案但由于不知道而做了其他复杂不成熟的方案所以广阔的技术视野是架构师的必备。 另外架构师不可能全部擅长在自己不擅长的点上需要知道找哪个专业的人是靠谱的这点也非常重要。二、在做系统设计时是否考虑到了足够多的方方面面 例如很多系统设计容易遗漏上线环节的细节导致在上线时发现漏掉了什么考虑临时解决或只能重来。 记得有一年我做的一个设计没有考虑到上线阶段的一个细节导致上线的时候发现由于网段的问题完全不work并且没有临时解决方案只好重来。 系统设计不仅仅指导研发同学怎么写代码也包括指导其他所有相关技术同学的工作。 又例如我2008年在做服务框架设计的时候集群和集群之间通过硬件负载均衡设备来访问的连接的方式是单个长连接这个设计导致了运行过程中如果要发布被调用的服务方很容易出现压力都集中在前面重启的机器上这也是典型的整个链路没有考虑清楚造成的设计问题。 再例如2013年我在做一个比较大范围的系统改造的设计时由于对其中一部分的软件了解得不够判断错误导致后来这个改造在进行过程中才发现有些需要改造的关键软件设计做得太粗糙最后上线进度差不多推迟了一个多月而且那些后来补的设计都是紧急做的风险非常高。 回顾自己设计过的软件发现在这个点上犯的错可以讲好几天看来我应该整理另外一篇文档《我在系统设计上犯过的xxx个错误》里面有些其实靠一份好的系统设计模板也许就能避免掉。一份好的系统设计模板是可以帮助架构师思考全面些的。 三、在做系统设计时是否考虑到了未来的一些发展尽可能不要出现未来的一点变化就导致现在白干或要花大量力气来改造的现象。 想当年做服务框架的时候后来就发现由于当年做设计的时候没有考虑到将来服务调用trace的问题导致了后来为了弥补这点花了巨大的力气不是技术上而是实施上。 全面需要架构师有足够广的技术领域知识和足够多的经验积累从全面这点就可以看到架构师的工作绝不是画几个框连几根线那么简单。 对架构师“全面”这点的挑战会随着系统的范围越大一个系统的设计和100个系统组成的大系统的设计挑战是完全不同的而变得越难无论是知识的广度、考虑的点的覆盖度、还是未来趋势更复杂的情况甚至会出现架构的调整对应着组织结构的调整这种也要考虑到例如服务化这种大的架构改造就意味着专职的专业领域服务团队的成立。 全局 全局观通常是指在系统设计时是否考虑到了对上下游的系统的影响。毕竟通常所设计的系统不是一个孤立的系统如果没有足够好的全局观有可能会导致自己的系统做完上线其他上下游系统尤其有些连上下游是谁怎么用都不知道的情况下出现问题。这种案例同样不少。 权衡 权衡同样也是架构师极度重要的能力。或者也可以认为是决策能力技术方案的拍板是一个架构师最重要的职责。 上面说的“全面”是架构师在思考时“放”的过程而权衡就是“收”的过程。收的过程结束基本就意味着技术方案的确定同时也确定了节奏。权衡在两点上会体现得特别突出 一、技术方案决策原则 通常一个问题都会有多种可解决的技术方案。怎么来决策就至关重要了而决策通常又和全面相关。大的来说通常决策的原则就是性价比和可持续发展。 性价比简单来说是方案的实现成本这个成本要包括非常多的方面。例如有些场景可能会是用硬件解决看起来是花钱但最终折算成本是最划算的很多系统设计在决策性价比时都过于随意例如一个另外常见的场景就是建设一套新系统替代旧系统这个时候可能完全没考虑旧系统的迁移代价甚至超过了改造旧系统的代价。 可持续发展简单来说就是所选择的技术方案在公司是否可持续。例如简单的案例是公司主体的研发人员都是php却搞一个其他语言且只有极少人懂的。当然这还是要看性价比如果搞一个其他语言带来的效益超过了语言/人才体系的更换成本。又例如引入一个开源产品有无专业团队维护这都是要考虑的关键因素。 二、优先级和节奏控制经常我会问做系统设计的同学一个问题对于这个业务场景而言在系统设计上最需要把握的一个点是什么。这是一个关键问题全面意味着考虑到了很多地方的问题但通常业务需求实现都是有很强的时间要求的因此在这个时候必须考虑清楚不同点的优先级同时也包括技术方案在决策时也要做出取舍有可能选了一个不是那么好的技术方案但通过留下一些可改造的空间为以后的重构做好铺垫那就是很不错的尤其技术同学有些时候比较容易陷入解决技术问题的场景去但那个问题其实有可能不是现阶段最重要的。 优先级和节奏控制是我认为一个最NB的架构师的最佳体现优先级意味着把握住了重点可以确保在所设计的架构指导下业务实现不会出现大问题节奏控制则意味着全面知道随着业务发展该在什么时间点做什么事为将来做好铺垫。转载于:https://www.cnblogs.com/zhjh256/p/6444535.html
