博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
云时代架构读后感4--IT架构的本质
阅读量:5855 次
发布时间:2019-06-19

本文共 1126 字,大约阅读时间需要 3 分钟。

IT架构的本质 原文地址:

这篇文章是由一位具有十二年工作经验的架构师总结而成,他从自己的工作经验中总结出五条道理:

1.需求优化最重要:少查少写少依赖,Less is more

2.群集设计通用规则:前端复制后端拆,实时改异步,三组件互换

3.理解硬件天性:角色选型时要看硬件的天然特性

4.数据的产生和消失:数据不会凭空产生,但会凭空消失

5.各环节都不可盲信:容灾设计中都尽人事和听天命

通过阅读他总结出的五条经验,应该会对我们以后的工作有所帮助。

在第一点中提到,一个IT系统是多角色多模块分层分级的,像OSI模型上层应用简单依赖下层支撑,SOA设计中同级角色也只看对方的接口。

各角色分工明确方便快速实现业务,但是给架构优化也埋下大坑,底层的盲目支撑是巨大资源浪费,平级调度协作也没任何弹性。

而做架构设计最重要的就是砍需求,将上层应用的需求优化删减,让同级的业务能容错。

前端对后端少输入少查询多容错,应该抓住核心诉求,不该要的东西都不要。

第二点指出,架构常见技巧就像空中华尔兹一样自然优雅。要做架构就要上群集,而群集设计调优翻来覆去就是这三板斧:前端复制后端拆,实时改异步,IO-算力-空间可互换。

前端是管道是逻辑,而后端是状态是数据,所以前端复制后端拆。

绝大部分“实时操作”都不是业务需求,而是某应用无法看到后端和Peer状态,默认就要实时处理结果了。

在群集性能规划中,网络和硬盘IO+CPU算力+磁盘和内存空间是可以互换的,架构师要完成补不足而损有余的选型。

第三点说道:别让硬盘扛性能,别让内存保持久,别让网线扛稳定。

架构层软件技术已经足够成熟,所谓技术选型不如说是适应场景;在做具体角色选型时,最深度也最易忽视的原则是顺应硬件天性。

如果一个服务依赖硬盘,那这个服务就不适合扛性能压力。

第四点告诉我们:数据不会凭空产生,我们要便捷轻巧安全可靠的获取数据,就要选好数据源,保障好传输路径,定义好数据变换规则。

但是会凭空消失,在一个数据生命周期内,为了防止数据全部或部分凭空消失,数据的容错校验、关联复原、冷热备份和安全删除都要考虑到位。

最后一点谈到,整个IT系统中就没有可靠的组件,架构师既不能盲目信任撞大运,又不能无限冗余吓唬自己,而是在尽人事和听天命之间做好权衡。

 

这篇文章主要讲的是架构工作的“道”,对与架构之“术”并不提及。不同的业务系统的架构之术完全不同,能拿来汇总借鉴的只有这几条简单的道理。

如果我们有架构之道做思想支撑,即使接手全新业务类型,庖丁可以解牛也可以杀猪,我们一样能游刃有余心里不慌。

 

转载于:https://www.cnblogs.com/sakura--/p/11050369.html

你可能感兴趣的文章
win7不能全屏
查看>>
MySQL/InnoDB的并发插入Concurrent Insert
查看>>
转两好文防丢:Debian 版本升级/降级 & Linux 应用程序失去输入焦点问题的解决...
查看>>
HDU - Pseudoforest
查看>>
Nexus杂
查看>>
Android --- GreenDao的实现(ORM框架)
查看>>
Linux平台Java调用so库-JNI使用例子
查看>>
Spring Data JPA
查看>>
项目管理修炼之道之规划项目
查看>>
Web服务器压力测试工具http_load、webbench、ab、Siege使用教程
查看>>
RHEL6.3 源码安装Puppet
查看>>
Mac软件下载备忘
查看>>
java 泛型初探
查看>>
在Linux中执行.sh脚本,异常/bin/sh^M: bad interpreter: No such file or directory
查看>>
就是一个表格
查看>>
CakePHP 2.x CookBook 中文版 第三章 入门 之 CakePHP 的结构
查看>>
Objective-C的算术表达式 .
查看>>
找回使用Eclipse删除的文件
查看>>
rabbitmq 消息系统 消息队列
查看>>
集成spring3、hibernate4、junit
查看>>