老僧三十年前未参禅时,见山是山,见水是水。

及至后来,亲见知识,有个入出,见山不是山,见水不是水。

而今得个休歇处,依前见山只是山,见水只是水。

参禅的三重境界在IT技术圈同样适用,初学者感叹每个产品都如此精妙绝伦,追逐着最强的IDE;老司机喜欢自比管乐指点江山,嘲讽着最好的语言;当一切回归平淡,搞IT就是一份思想延伸和语言翻译工作;其中技术架构师就是一份古朴甚至无趣的工作。

一位架构师将他的工作总结出五条核心道理,这五条经验简单直白又深奥通透,算是对十二年IT工作的一个总结。

1. 需求优化最重要

——少查少写少依赖,Less is more

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

各角色分工明确方便快速实现业务,但是给架构优化也埋下大坑,底层的盲目支撑是巨大资源浪费,平级调度协作也没任何弹性。前端一个小逻辑需求会导致后端大规模联动,不同服务也没权限理解对方的内存数据,各个角色的工程师都只看自己的工作范围,这是正常又无奈的现状。

我们要搞架构设计最重要的就是砍需求,将上层应用的需求优化删减,让同级的业务能容错。上层需求优化,即前端对后端少输入少查询多容错,而同级容错可以看做应用间的需求优化,比如两个服务可以幂等重试就是好解耦,而A系统会等B系统等到死锁就是架构悲剧。

某电商ERP系统的用户点一次查询按钮,后台系统就锁库查询一次;实操过程中系统越慢用户就重复点查询按钮,而并行查询越多后台速度就更慢。这种环境要搞架构优化,首先要理解自然人并不要求实时数据,ERP客户端限制每15秒才能点一次查询按钮,在Web接入层限制每个Session每分钟只能查询一次,还可在数据库链接类库上做一层控制策略。

多媒体服务工程师最好的情人节礼物会是一个完美的播放器;它可以自助容错选择CDN,可以主动预缓存下一分钟的点播内容,可以完成私有解密编码工作,可以和广告系统解耦独立加载,可以在卡顿时更换线路和存储日志,广告日志和卡顿日志都低速适时后台上传。

2.群集设计通用规则

——前端复制后端拆,实时改异步,三组件互换

前端复制后端拆,实时改异步,IO-算力-空间可互换——要做架构就要上群集,而群集设计调优翻来覆去就是这三板斧:

前端是管道是逻辑,而后端是状态是数据,所以前端复制后端拆。前端服务器压力大了就多做水平复制扩容,在网站类应用上,无状态-会话保持-弹性伸缩等技术应用纯熟。后端要群集化就是多做业务拆分,常见的就是数据库拆库拆表拆键值,服务拆的越散微操作就越爽,但全局操作开销更大更难控制。

实时改异步是我学的最后一门IT技术,绝大部分“实时操作”都不是业务需求,而是某应用无法看到后端和Peer状态,默认就要实时处理结果了。CS模式的实时操作会给支撑服务带来巨大压力,Peer合作的实时操作可能会让数据申请方等一宿。架构师将一个无脑大事务拆分成多个小事务,这就是异步架构,但拆分事务就跟拆分数据表一样,拆散的小事务需要更高业务层级上做全局事务保障。

在群集性能规划中,网络和硬盘IO+CPU算力+磁盘和内存空间是可以互换的,架构师要完成补不足而损有余的选型。比如数据压缩技术就是用算力资源来置换IO和空间,缓存技术是用空间和IO来缓解算力压力,每个新选型都会带来细节上的万千变化,但每种变化都是符合自然规律有章可循的。 一个经典微机系统就是中央处理器+主存储器+IO设备,这几个概念居然和群集性能规划是一一对应。

3. 理解硬件天性

——角色选型时要看硬件的天然特性

别让硬盘扛性能,别让内存保持久,别让网线扛稳定。

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

我的精神导师说过,如果一个服务依赖硬盘,那这个服务就不适合扛性能压力。我经常将读写引到/dev/shm;SSD盘让很多细节调优聊胜于无,还让Fat32枯木逢春;个别队列和分布式存储在意硬盘的性能力,但都是应用了顺序读写内容,且不介意磁盘空间浪费。

别让内存扛持久和别让网线扛稳定,听起来很简单,但新手程序员总会犯低级错误,而犯错早晚要还技术债。常规例子就是看新手程序是否有捕获各种异常的习惯,举个争议性例子,某些云服务设计者尝试给一个进程映射和绑定持久文件系统,请问一段内存如何绑定一块硬盘?

4. 数据的产生和消失

——数据不会凭空产生,但会凭空消失

数据不会凭空产生,计算机或者自输入设备获取数据,或者自其他数据源导入数据,而且原始数据的转化规则也要人类来定义。我们要便捷轻巧安全可靠的获取数据,就要选好数据源,保障好传输路径,定义好数据变换规则。

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

在生僻业务的规划实施过程中,没人告诉我们该有哪些服务,我们只能靠摸透一个又一个访问逻辑图和数据生命周期,来摸索群集内有哪些角色和依赖关系。

架构师的核心技能包括画好访问逻辑和数据流量图,因为问题现状描述清楚了,问题就解决了一多半了。一个好的业务访问逻辑图,不仅仅是几个圈圈几条线连起来,其信息量大到包罗访问过程的所有元素,也要详略得当高亮关键点。

5. 各环节都不可盲信

——容灾设计中都尽人事和听天命

整个IT系统中就没有可靠的组件,架构师既不能盲目信任撞大运,又不能无限冗余吓唬自己,而是在尽人事和听天命之间做好权衡。比如TCP就是要建立可靠链接,而现在做性能优化的时候,大家又嫌TCP太过笨重了。

  1. 业务应用不可靠,如果该应用能快速重建也不阻塞其他应用,月级偶发的内存泄漏和意外崩溃都是可以接受的。
  2. 支撑性服务不可靠,对于大部分业务,预估一年都不丢一次数据,SLA能到99.95%就可以了。
  3. 操作系统故障崩溃,现在商用系统内核都很稳定,一般故障都出在硬件驱动兼容性上,或者有些照本宣科的傻瓜乱改默认参数。
  4. 网络不稳定,内网通用的技术方案很成熟,少提复杂需求内网就能很稳定,我们最烦的是单条网线处于半死不活状态;IDC的外网SLA默认就是3个9,所以我说支撑性服务能到99.95%就已经很可靠了。
  5. 硬件不稳定,大部分架构师根本不懂硬件,只要不出硬件批次故障,架构师就可以将单点硬件和系统、服务绑在一起做可靠性设计。
  6. 人力误操作,我们招不到不出故障的人,我自己达不到不出错的标准。只要员工没有恶意破坏,出了大范围故障就是群集健壮性设计不到位,别让操作工给技术总监和架构师顶包。
  7. 监控和备份是运维的职责,但架构师需要帮忙确认目的正确性,别备份了半天废数据,监控只看telnet80。

结束语

——架构之术繁琐,架构之道浅显

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

如果一个架构师只是炫耀具体优化架构的手法,却闭口不谈选型的道理,他们其实是在简单用公司业务尝试赌博。

如果我们有架构之道做思想支撑,即使接手全新业务类型,庖丁可以解牛也可以杀猪,我们一样能游刃有余心里不慌。我曾经接手三种生僻晦涩的业务,按照本文的原理去拆解和规划,就没有什么特别难的。

转自:https://mp.weixin.qq.com/s/QdCV78fM7kNkvdjHZRzTIA

IT架构的本质的更多相关文章

  1. paip.性能跟踪profile原理与架构与本质-- python扫带java php

    paip.性能跟踪profile原理与架构与本质-- python扫带java php ##背景 弄个个输入法音标转换atiEnPH工具,老是python性能不的上K,7k记录浏览过k要30分钟了. ...

  2. 沉淀再出发:jetty的架构和本质

    沉淀再出发:jetty的架构和本质 一.前言 我们在使用Tomcat的时候,总是会想到jetty,这两者的合理选用是和我们项目的类型和大小息息相关的,Tomcat属于比较重量级的容器,通过很多的容器层 ...

  3. IT架构的本质--阅读笔记01

    万物都有其本质,也只有了解了事物的本质之后,才不至于出现在事物稍作改变时就难以应对的情况,作为软件工程专业的学生,我们应该对IT架构的本质有一定的了解.“老僧三十年前未参禅时,见山是山,见水是水.及至 ...

  4. Web基础架构:负载均衡和LVS

    在大规模互联网应用中,负载均衡设备是必不可少的一个节点,源于互联网应用的高并发和大流量的冲击压力,我们通常会在服务端部署多个无状态的应用服务器和若干有状态的存储服务器(数据库.缓存等等). 一.负载均 ...

  5. [转]Web基础架构:负载均衡和LVS

    以下内容转载自:http://www.importnew.com/11229.html 在大规模互联网应用中,负载均衡设备是必不可少的一个节点,源于互联网应用的高并发和大流量的冲击压力,我们通常会在服 ...

  6. REST架构实质(转)

    REST(Representational State Transfer) 曾经被误解为只是CRUD(增删改查),从这个层面上,好像REST只是和RPC一个层面的东西,没有什么了不起,其实这些都是对R ...

  7. LevelDB架构

    LevelDB系列之整体架构   LevelDb本质上是一套存储系统以及在这套存储系统上提供的一些操作接口.为了便于理解整个系统及其处理流程,我们可以从两个不同的角度来看待LevleDb:静态角度和动 ...

  8. 企业架构与建模之使用ArchiMate进行分析

    企业架构与建模之使用ArchiMate进行分析(全系列完) 4. 使用ArchiMate进行分析 正如前面所说的那样,一个企业整体效率的提升有时并不是通过某一个领域内的优化就能达到的,而且这种忽视全局 ...

  9. 企业架构研究总结(45)——企业架构与建模之使用ArchiMate进行分析(全系列完)

    4. 使用ArchiMate进行分析 正如前面所说的那样,一个企业整体效率的提升有时并不是通过某一个领域内的优化就能达到的,而且这种忽视全局的做法往往还会造成不必要的浪费.由此可见,一个能够跨越各个领 ...

随机推荐

  1. python第三方库安装

    如安装jieba分词库 代码对Python 2/3均兼容 全自动安装:easy_install jieba或者pip install jieba / pip3 install jieba 半自动安装: ...

  2. luogu 1169 [ZJOI2007]棋盘制作 悬线dp

    悬线法,虽然得不到局部最优解,但是一定能得到全局最优解的算法,十分神奇~ #include <cstdio> #include <algorithm> #define N 20 ...

  3. Java源码分析-UUID

    原文链接:Little Apple's Blog 本文分析的JDK版本为1.8.0_131. UUID? UUID是Universally Unique Identifier的缩写:Java UUID ...

  4. 使用Camtasia 9 录制屏幕软件

    Camtasia 9 录制屏幕软件,并且有丰富的专业剪辑功能.

  5. Python实用黑科技——解包元素(1)

    需求: 很多时候手上已经有了一个具有n个元素的列表或者元组,你打算把这些元素单独取出来(解包)放入n个变量组成的集合(这里的集合和Python自己的set不同)中. 方法: 显然,最好的办法就是直接用 ...

  6. 一、微服务(Microservices)【翻译】

    1.微服务 “微服务架构(Microservice Architecture)”一词在过去几年里广泛的传播,它用于描述一种设计应用程序的特别方式,作为一套独立可部署的服务.目前,这种架构方式还没有准确 ...

  7. HDU 5974 A Simple Math Problem ——(数论,大连区域赛)

    给大一的排位赛中数论的一题.好吧不会做...提供一个题解吧:http://blog.csdn.net/aozil_yang/article/details/53538854. 又学了一个新的公式..如 ...

  8. ew做代理 进一步内网渗透

    0x00 前言 最近搞站的时候有内网穿透的需求,大佬向我推荐了EW,本文模拟一个攻击场景对Earthworm的使用方法做一个简单的介绍.其实相应的内容EW的官网已经说得很详细了,我这里纯粹是作为个人笔 ...

  9. 【零基础】搞定zabbix安装

    一.前言 最近想做服务器压力测试,测试软件找到了,突然发现还没有很好的办法监控服务器运行情况,之前用过zabbix,所以想到说要不就用zabbix来监控服务器运情况,不过这次就要好好研究下zabbix ...

  10. selenium 右侧滚动条操作

    对于web上有右侧滚动条的操作 可用使用JS语句执行 拖到底部 js = "var q=document.documentElement.scrollTop=10000"brows ...