[系统架构]抛砖引玉:闲聊下架构、框架,以及架构师

??

我们先来看看本人对以下这两个名词的个人见解:

  • 软件架构:

差点儿每一个软件系统的架构都是不同的,因为软件架构的第一步就是依据当前项目的重要需求及约束来制定一个个技术决策。

  • 软件框架:

能够分成行业框架和通用框架。

    1. 通用框架是对大多数软件项目经常使用的模块(底层+高层)进行封装(同一时候暴露热点)的一个集合。能提高开发速度以及质量
    2. 行业框架是针对某特定领域,把相似领域逻辑提取出来进行封装(同一时候暴露热点)的一个集合。能提高开发速度以及质量
    3. 行业框架能够是基于通用框架之上的。

站在架构师的角度,针对架构的开发。会慢慢演变为针对框架的开发(因为须要考虑复用以及对开发者友好API特性)

  • 伸缩性:通常是指机器级别的横向扩展,如:webserver的横向扩展、数据库的读写分离、中间件的横向扩展
  • 扩展性:是指当需求变更时,系统是否能非常easy的进行改动、扩展。

  • 简洁性:直接的观念是AOP。因为AOP能让开发者集中注意力于业务逻辑上,而不须要过多考虑非业务逻辑代码(比方日志、权限、參数的基本验证等)
  • 性能:与伸缩性、算法优化、充分利用CPU能力有关

因为每一个项目都是不同的,因此架构也大多数不同。可是因为人的精力有限。不可能样样都精通,因此当架构初始化之后,针对不熟悉的
架构还须要进行架构验证(如同測试人员的BVT)。

因此对架构师而言,个人的学习能力、学习速度以及实践能力都非常重要。那么怎样进行架构验证呢?
1. 找几个开发者评审评审框架提供的API,看看反馈,须要改动则改动。或者通过技术培训解决
2. 使用AOP技术插入必要的日志、性能计数器、内存占用数(当然也能够用其它技术,并不是仅仅有AOP技术)
3. 自己进行性能測试、性能分析;或者找技术性測试人员来做

最后别忘了当项目进行之前先进行技术培训,解说框架的实现原理以及怎样使用。

综上所述,框架与架构质量的好坏会严重影响使用者的效率。如:开发者的开发效率。架构师责任重大啊。

附上一个架构总览图:

欢迎大家来跟帖讨论哈

时间: 2024-11-16 17:44:17

[系统架构]抛砖引玉:闲聊下架构、框架,以及架构师的相关文章

闲聊下架构、框架,以及架构师

我们先来看看本人对下面这两个名词的个人见解: 软件架构:几乎每个软件系统的架构都是不同的,因为软件架构的第一步就是根据当前项目的重要需求及约束来制定一个个技术决策. 软件框架:可以分成行业框架和通用框架. 通用框架是对大多数软件项目常用的模块(底层+高层)进行封装(同时暴露热点)的一个集合,能提高开发速度以及质量行业框架是针对某特定领域,把类似领域逻辑提取出来进行封装(同时暴露热点)的一个集合,能提高开发速度以及质量行业框架可以是基于通用框架之上的.站在架构师的角度,针对架构的开发,会慢慢演变为

系统架构师-基础到企业应用架构-系统建模[中篇](下)

一.上章回顾 首先.我们先来回顾下,上篇讲解的内容,加深下印象.上篇我们主要讲解了3个建模图形分别是:顺序图(序列图).组件图.状态图. 具体功能描述如下图:这里不详细解释,如果不清楚请看:系统架构师-基础到企业应用架构-系统建模[中篇](上) 由于全部放在一篇中篇幅太长了,所以分开讲解. 二.摘要 本文主要讲解:UML建模图中的活动图.部署图等 上图中就是本章要讲解的内容,本质将仔细的剖析,部署图与组件图的关系与区别,活动图与状态图的关系与区别. 三.本章内容 1.上章回顾. 2.摘要. 3.

遗留系统SOA之(2)——SOA架构基础概念与设计框架

SOA的设计框架 设计框架与架构相关的概念紧密相连,原则.模式和架构始终是与设计共舞的. SOA服务设计的原则中记录了一个基础的设计框架: 设计特性(Design Characteristic)——由设计产生的软件程序或技术架构的属性.它可以是任何具体的质量要求,比如程序组件化,功能粒度的粗细等. 设计原则(Design Principles)——一个针对具体设计目标且被业界接受的实践方式.面向服务的设计范式包括了一个以实现面向服务计算为目的的设计原则集合. 设计模式(Design Patter

java设计模式、框架、架构、平台之间的关系

    设计模式<框架<架构<平台,从复用角度讲,设计模式是代码级复用.框架是模块级复用.架构是系统级复用.平台是企业应用级复用. 1.设计模式 为什么要先说设计模式?因为设计模式在这些概念中是最基本的,而且也比较简单.那么什么是设计模式呢?说的直白点,设计模式就是告诉你针对特定问题如何组织类.对象和接口之间的关系,是前人总结的经验.比如我要在代码中实现一个全局唯一的配置类,那么就使用Singleton模式.设计模式在实际编码工作和设计框架时会被使用到,而更高层的架构和平台则不会太关注它

雪球在股市风暴下的高可用架构改造分享

本文根据唐福林老师在“高可用架构”微信群所做的<股市风暴下的雪球架构改造经验分享>整理而成,转发请注明来自微信公众号ArchNotes. 唐福林,雪球首席架构师,负责雪球业务快速增长应对及服务性能与稳定架构优化工作.毕业于北京师范大学,硕士学位.之前曾任微博平台资深架构师,微博技术委员会成员.长期关注并从事互联网服务后端性能及稳定性架构优化工作. 雪球公司介绍 雪球 聪明的投资者都在这里. web 1.0:新闻资讯,股价信息,K线图 web 2.0:SNS 订阅,分享,聊天 web 3.0:移

多研究些架构,少谈些框架

论微服务架构的核心概念 微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者说SOA(面向服务架构)是什么区别呢? 我们先看相同点: 需要Registry,实现动态的服务注册发现机制: 需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑: 同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息:

多研究些架构,少谈些框架(1) -- 论微服务架构的核心概念(转)

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者说SOA(面向服务架构)是什么区别呢?我们先看相同点: 需要Registry,实现动态的服务注册发现机制: 需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑: 同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息: 都需要统一的Gateway

多研究些架构,少谈些框架(1):论微服务架构的核心概念

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为新的理念和原来的分布式系统,或者说SOA(面向服务架构)是什么区别呢? 我们先看相同点: 需要Registry,实现动态的服务注册发现机制:需要考虑分布式下面的事务一致性,CAP原则下,两段式提交不能保证性能,事务补偿机制需要考虑:同步调用还是异步消息传递,如何保证消息可靠性?SOA由ESB来集成所有的消息:都需要统一的Gateway来汇

亿级用户下的新浪微博平台架构读后感

阅读文章:亿级用户下的新浪微博平台架构 文章网址:https://mp.weixin.qq.com/s?__biz=MzA3NzgzMzUxMw==&mid=203412989&idx=4&sn=2df0c60f56ae1e228ff269420803c3ef&scene=21#wechat_redirect 微博平台第一代架构为LAMP架构,数据库使用的是MyIsam,后台用的是php,缓存为Memcache. 随着应用规模的增长,衍生出的第二代架构对业务功能进行了模块化