云时代架构读后感4--IT架构的本质

IT架构的本质 原文地址：http://mp.weixin.qq.com/s?__biz=MzAwNTQ4MTQ4NQ==&mid=2453562304&idx=1&sn=be86a7bc682c4e76e06b87a10ad45188&chksm=8cd136a2bba6bfb430103e50f94b670e799412d0a1cae4eded0eb901847b6d462359ae317635&mpshare=1&scene=23&srcid=#rd

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

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

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

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

4.数据的产生和消失：数据不会凭空产生，但会凭空消失

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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