企业IT架构转型之道 - 读书 - 张子阳的博客

企业IT架构转型之道

2018-6-23 张子阳 推荐: 3 难度: 4

近期公司在做一些后台架构方面的改造,例如对数据中心,数据采集/传输/清洗/存储方面的优化,因此,我想有必要了解一些其他公司是如何做系统架构和转型的,于是购买了这本书。通读完以后,对阿里的中台架构有一个鸟瞰式的了解,也了解到了其中的庞大和复杂。这样的系统规模,对于大多数公司都是难以实现的,既难以开发也难以维护,毕竟很少有公司达到阿里这样的量级(不管是面对的客户访问量还是技术人员的数量)。但是,从这本书中,至少看到了架构的一些演化过程、可能遇到的问题、可选的解决方案。这样,在公司逐步发展时遇到类似问题时,至少有一个解决问题的方向,然后按这个方向再去寻找具体的解决办法。

下面是书中讲到的一些对我有所启发的知识点:

共享事业部

这本书主要讲“中台战略思想与架构”,那么什么是中台?在这本书中,中台的概念主要是指“共享服务”,负责的部门是一个独立的事业部:共享业务事业部。这个事业部主要包含的几大部分有:用户中心、商品中心、交易中心、评价中心、店铺中心、搜索中心、营销中心等。它的上游,是天猫、淘宝、1688、阿里去啊、菜鸟物流等前端业务部;下游,是阿里云平台,包括弹性计算服务、关系型数据库服务、消息队列服务、开放存储服务、开放缓存服务等IT基础设施。

企业项目架构的演化

  1. 传统的“烟囱式”的架构方式,项目林立,各自拥有孤立的数据,彼此之间数据打通和同步耗时费力。
  2. 采用SOA的架构方式,各个项目和系统通过ESB(企业服务总线)进行消息通信。
  3. 去中心化的微服务架构,各个服务彼此独立和自治,服务之间直接调用。

怎么叫懂业务?

当说到开发人员“不懂业务”时,开发人员往往会说:系统都是我们开发的,具体流程、操作、数据模型方面,甚至比业务部门更懂。而实际上所谓的懂业务,应当是指:能对业务的下一步发展有自己的理解和看法,对业务流程如何进一步优化能更好地提升业务有独到的见解,甚至对企业现有的业务提出创新的想法,为企业带来新的增长点。

集群雪崩

假设有一个5台服务器的集群,负载都达到了80%;此时如果1台故障,那么其余4台负载都将达到100%,这样其余4台也变得不稳定,此时如果1台挂掉,就会引发雪崩效应:其他三台负载(133%)全部挂掉。当集群因为不堪重负挂掉之后,此时又会面临一个重启的难题:除非5台同时启动,否则,当1台先启动时,就会立即因为过载而挂掉。因此,就需要先关闭前端的网关,待集群中的服务器全部启动后再打开。

异构索引表

当数据量很大时,通常都会进行分库分表,比如说企业中常见的订单表。常见的订单表包含下面的字段:

订单号,卖家Id,买家Id,订单金额,下单时间。

常见的一种分表方式,就是对单号哈希后取模,例如分8张表,则对单号除以8,根据余数存到对应的表中。这种方式在对单号查询时异常迅速,因为只要根据单号得到要查询的分区表,然后去分表中查询就可以了。

但是,对于其余几种常见的查询,却要进行全表扫描。例如,查询某位买家、某位卖家,或者某个时间段内的订单。此时,可以通过构建一个冗余的异构索引表来完成。例如,建这样下面一张表:

买家Id,订单号

然后再根据买家Id进行哈希后取模进行分表。这样当需要查询某个买家的订单时,则分为了三个步骤:1、先根据买家Id,到异构索引表的分表中取得订单号;2、根据订单号,到主表的分表中取数据;3、将查询的订单结果进行聚合返回给调用者。

分布式事务

CAP理论:一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance)这三项中的两项。

实现的机制是拥有一个中心的事务协调服务。假设有一次客户端的请求,需要依次调用两个服务A、B,这两个服务分别修改各自数据库中的表 X,Y。

  1. 在调用服务A,执行对表X的操作前,解析 Insert/Update/Delete语句,将要修改的记录保存一份,标记为Undo,用于将来回滚。
  2. 执行实际的SQL语句,执行完成后,将修改后的记录保存一份,记为Redo。作为回滚前的校验(可能存在其他线程在回滚前将数据修改了,此时记录值将会与保存的Redo记录不一致)。
  3. 调用服务B,如果服务B执行成功,则删除 Redo/Undo 记录;如果服务B执行失败,则对服务A进行回滚。

回滚的步骤为:

  1. 对比Redo与当前记录是否一致,如果一致,则使用Undo日志进行回滚。
  2. 如果不一致,说明数据被其他线程更改了,此时无法自动回滚,应该抛出异常(或者发出提醒),需要人工干预。

服务调用路径和记录

设想一下,当一次请求调用了数十个微服务时,排错和调试将会是非常困难的一件事情。因此,需要一个统一的方法,来记录服务的调用链路(通过唯一的TraceId)。

类似于高速公路,几点几分到达了哪个收费站,交了多少费用(行驶了多少里程)。对于微服务而言,则是几点几分调用了哪个服务,上一个服务执行了多长时间。与高速公路不同的时,服务还有有个“并行度”的概念,即几个服务同时执行。

这个很类似于当我们使用Chrome浏览器时,按下F12键时,看到的资源加载的顺序、并行度和调用时长。

Chrome浏览器查看资源加载的顺序、并行度和时长

阿里有一个鹰眼系统专门进行这件事,但是我们公司暂时还没有实现,以后如果全面微服务话,这样的基础组件也是必不可少的。

服务能力输出

书中的最后介绍了两个案例,即阿里的技术能力输出,帮助大型企业进行互联网技术的转型。实际上,阿里云已经是阿里进行技术输出的一个典型了。之前这些技术都是阿里内部使用,最终成熟稳定后,开始向外部输出。对于企业来说,减少了运维的工作,对阿里来说,创造了新的业务点,可以说是双赢的。

对于普通规模的公司而言,虽然不一定像阿里那样输出IT基础设施服务(云服务、数据库、缓存等),但是却可以将一些业务服务打包起来,向下游或者同业的小型公司输出,提升其开发效率和稳定性,做得好的话也是双赢的。

感谢阅读,希望这篇文章能给你带来帮助!