众所周知,架构师的角色,更偏向于策划、而非指挥,塑造、而非支配,其存在的意义,在于引导大家讨论、而非自己主宰一切。
但是,具体应该如何执行呢?本文作者整理了 30 个公认的架构原则,来帮助大家解决此问题。也许有的原则,你从未听说,但你看完就能快速学会。
相信你学会了,工作起来也会事半功倍,或许还可帮你避免很多无用的加班!
本文作者叫 Srinath Perera,是一位计算机科学家、软件架构师、作家。他是 Apache 的核心成员,拥有 15 年分布式系统编程经验,设计了 Apache Axis2 以及 WSO2 流处理器。
在 WSO2,我参与架构评审的时间已长达八年之久。WSO2 的产品非常丰富,比如 WSO2 ESB 、WSO2 api Manager 以及 WSO2 SP 都人尽皆知。在过去八年中,我们对许多产品和功能进行了讨论、设计、改进和重新设计。
我们在设计软件的过程中,把握的一个关键点是:软件架构并非由架构师负责设计。我们的架构不是由架构师制定,然后交给其他人来实施。
相反,架构的设计任务由真正编写代码的团队负责。架构师负责对工程师设计的架构进行修复、完善和改进。我们的架构团队是指导员和把关人,而非独裁者。
在短期内,由一位架构师来制定架构的确既快捷又实惠。但是,从长远来看,我们会组建一个团队,让他们自己不断思考、改善架构,并从他们的错误中来提升自己。
当我们专注于团队时,他们自然会随着时间的推移而变得更好。架构团队的首要任务是:尽可能保证架构容易执行。此外,架构评审也存在缺陷。
就像 Paul (@pzfreo)描述的架构评审那样:架构师参与进来,听一会,发表一点评论然后就走了。作为一名架构师,你对架构发表自己的看法和意见无可厚非。但是,如果你不够投入和细心,你的意见可能会让团队感到困惑,团队就无法确定正确的做法到底是什么。
接下来我会将 30 个架构原则一一列出,其中一些原则是众所周知的,而有些则源于我的个人经验和心血。
基本原则
最后,谈一下我的感受。在理想情况下,一个平台应当由多个正交组件组成,每个组件负责一个方面(例如,安全性、消息传递、注册、调解、分析,等等)。使用这些功能构建的系统将是很好的。
不幸的是,现实中我们很难达到这样的状态。因为在项目初始状态时,很多事情是不确定的,你无法做到这样的独立性,现在我认为在开始的时候适当的重复是必要的,当你尝试铲除他们的时候,你会发现引入了新的复杂性,分布本身就意味着复杂。有时候治愈的过程要比疾病本身更加的糟糕。
作为一个架构师,我们应该像园丁一样思考、塑造、策划和去除杂草而不是定义和构建。虽然在短期内,由一位架构师来制定架构的确既快捷又实惠。但是,从长远来看,团队的力量才是强大的。
如果你不够投入和细心,你只指出错误,但是不道明错误原因,那么你的意见可能会让团队感到困惑。避免这种情况的一种方法是拥有一套普遍接受的原则,这些原则是讨论架构时遵循的基本点,也是初学者学习架构的好资源。所以想成为一名优秀的架构师,还是需要长期的磨练以及时间的验证,当然随时保持学习的状态也是非常重要的。当你学会更多知识,你便会更清晰的解决各种复杂的架构问题。
原文 http://developer.51cto.com/art/201910/604592.htm
架构和框架是独立的,本文仅仅是提出一种架构思路,而且这个架构也在百度的某款用户量很大的复杂前端产品中得以应用。基于这一套弹性架构并结合Vue/React的现代化开发理念,可以很好的完成高复杂度的前端系统。
软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。传统软件架构描述的对象是直接构成系统的抽象组件,侧重于系统的抽象、拆分、组织方式等
架构师的一个重要职责是,确保团队有共同的技术愿景,以帮助我们向客户交付他们想要的系统。在某些场景下,架构师只需要和一个团队一起工作,这时他们等同于技术引领者。在其他情况下,他们要对整个项目的技术愿景负责,通常需要协调多个团队之间,甚至是整个组织内的工作。
C/S 架构是一种典型的两层架构,其全程是Client/Server,即客户端服务器端架构,其客户端包含一个或多个在用户的电脑上运行的程序,而服务器端有两种,一种是数据库服务器端,客户端通过数据库连接访问服务器端的数据
目的为保证服务器硬件故障时依然可用,数据依然保持并能够访问,手段:数据和服务的冗余备份以及失效转移机制,有状态 :在服务端保留之前的请求信息,用以处理当前请求(例如:session)无状态 :没有特殊状态的服务
动态应用,是相对于网站静态内容而言,是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件,比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。
本来没想写这个题材的,为了某某童鞋能够更好的茁壮成长,临时写一篇负载均衡的。负载均衡,大家可能听过什么3层负载均衡、4层负载均衡、7层负载均衡什么的?那这是怎么分的呢,ok,是根据osi七层网络模型来分的,例如nginx是工作在应用层
Kubernetes(k8s)是一款开源的优秀的容器编排调度系统,其本身也是一款分布式应用程序。虽然本系列文章讨论的是互联网架构,但是k8s的一些设计理念非常值得深思和借鉴,本人并非运维专家,本文尝试从自己看到的一些k8s的架构理念结合自己的理解来分析 k8s在稳定性
一般来说,除了当前的系统功能需求外,软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。性能是网站的一个重要指标,任何软件架构设计档案都必须考虑可能会带来的性能问题。
本章介绍如何去构建高可用的服务,关键词:服务分级,超时设置,异步调用,服务降级,幂等性设计,一些架构设计中的常用方案,但是需要结合实际业务场景进行设计,没有一套方案能解决所有问题
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!