企业IT架构转型之道
2018-6-23 张子阳 推荐: 3 难度: 4
近期公司在做一些后台架构方面的改造，例如对数据中心，数据采集/传输/清洗/存储方面的优化，因此，我想有必要了解一些其他公司是如何做系统架构和转型的，于是购买了这本书。通读完以后，对阿里的中台架构有一个鸟瞰式的了解，也了解到了其中的庞大和复杂。这样的系统规模，对于大多数公司都是难以实现的，既难以开发也难以维护，毕竟很少有公司达到阿里这样的量级（不管是面对的客户访问量还是技术人员的数量）。但是，从这本书中，至少看到了架构的一些演化过程、可能遇到的问题、可选的解决方案。这样，在公司逐步发展时遇到类似问题时，至少有一个解决问题的方向，然后按这个方向再去寻找具体的解决办法。
下面是书中讲到的一些对我有所启发的知识点：
共享事业部
这本书主要讲“中台战略思想与架构”，那么什么是中台？在这本书中，中台的概念主要是指“共享服务”，负责的部门是一个独立的事业部：共享业务事业部。这个事业部主要包含的几大部分有：用户中心、商品中心、交易中心、评价中心、店铺中心、搜索中心、营销中心等。它的上游，是天猫、淘宝、1688、阿里去啊、菜鸟物流等前端业务部；下游，是阿里云平台，包括弹性计算服务、关系型数据库服务、消息队列服务、开放存储服务、开放缓存服务等IT基础设施。
企业项目架构的演化
- 传统的“烟囱式”的架构方式，项目林立，各自拥有孤立的数据，彼此之间数据打通和同步耗时费力。
- 采用SOA的架构方式，各个项目和系统通过ESB（企业服务总线）进行消息通信。
- 去中心化的微服务架构，各个服务彼此独立和自治，服务之间直接调用。
怎么叫懂业务？
当说到开发人员“不懂业务”时，开发人员往往会说：系统都是我们开发的，具体流程、操作、数据模型方面，甚至比业务部门更懂。而实际上所谓的懂业务，应当是指：能对业务的下一步发展有自己的理解和看法，对业务流程如何进一步优化能更好地提升业务有独到的见解，甚至对企业现有的业务提出创新的想法，为企业带来新的增长点。
集群雪崩
假设有一个5台服务器的集群，负载都达到了80%；此时如果1台故障，那么其余4台负载都将达到100%，这样其余4台也变得不稳定，此时如果1台挂掉，就会引发雪崩效应：其他三台负载（133%）全部挂掉。当集群因为不堪重负挂掉之后，此时又会面临一个重启的难题：除非5台同时启动，否则，当1台先启动时，就会立即因为过载而挂掉。因此，就需要先关闭前端的网关，待集群中的服务器全部启动后再打开。
异构索引表
当数据量很大时，通常都会进行分库分表，比如说企业中常见的订单表。常见的订单表包含下面的字段：
代码语言：txt复制订单号，卖家Id，买家Id，订单金额，下单时间。常见的一种分表方式，就是对单号哈希后取模，例如分8张表，则对单号除以8，根据余数存到对应的表中。这种方式在对单号查询时异常迅速，因为只要根据单号得到要查询的分区表，然后去分表中查询就可以了。
但是，对于其余几种常见的查询，却要进行全表扫描。例如，查询某位买家、某位卖家，或者某个时间段内的订单。此时，可以通过构建一个冗余的异构索引表来完成。例如，建这样下面一张表：
代码语言：txt复制买家Id，订单号然后再根据买家Id进行哈希后取模进行分表。这样当需要查询某个买家的订单时，则分为了三个步骤：1、先根据买家Id，到异构索引表的分表中取得订单号；2、根据订单号，到主表的分表中取数据；3、将查询的订单结果进行聚合返回给调用者。
分布式事务
CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
实现的机制是拥有一个中心的事务协调服务。假设有一次客户端的请求，需要依次调用两个服务A、B，这两个服务分别修改各自数据库中的表 X，Y。
- 在调用服务A，执行对表X的操作前，解析 Insert/Update/Delete语句，将要修改的记录保存一份，标记为Undo，用于将来回滚。
- 执行实际的SQL语句，执行完成后，将修改后的记录保存一份，记为Redo。作为回滚前的校验（可能存在其他线程在回滚前将数据修改了，此时记录值将会与保存的Redo记录不一致）。
- 调用服务B，如果服务B执行成功，则删除 Redo/Undo 记录；如果服务B执行失败，则对服务A进行回滚。
回滚的步骤为：
- 对比Redo与当前记录是否一致，如果一致，则使用Undo日志进行回滚。
- 如果不一致，说明数据被其他线程更改了，此时无法自动回滚，应该抛出异常（或者发出提醒），需要人工干预。
服务调用路径和记录
设想一下，当一次请求调用了数十个微服务时，排错和调试将会是非常困难的一件事情。因此，需要一个统一的方法，来记录服务的调用链路（通过唯一的TraceId）。
类似于高速公路，几点几分到达了哪个收费站，交了多少费用（行驶了多少里程）。对于微服务而言，则是几点几分调用了哪个服务，上一个服务执行了多长时间。与高速公路不同的时，服务还有有个“并行度”的概念，即几个服务同时执行。
这个很类似于当我们使用Chrome浏览器时，按下F12键时，看到的资源加载的顺序、并行度和调用时长。
Chrome浏览器查看资源加载的顺序、并行度和时长
阿里有一个鹰眼系统专门进行这件事，但是我们公司暂时还没有实现，以后如果全面微服务话，这样的基础组件也是必不可少的。
服务能力输出
书中的最后介绍了两个案例，即阿里的技术能力输出，帮助大型企业进行互联网技术的转型。实际上，阿里云已经是阿里进行技术输出的一个典型了。之前这些技术都是阿里内部使用，最终成熟稳定后，开始向外部输出。对于企业来说，减少了运维的工作，对阿里来说，创造了新的业务点，可以说是双赢的。
对于普通规模的公司而言，虽然不一定像阿里那样输出IT基础设施服务（云服务、数据库、缓存等），但是却可以将一些业务服务打包起来，向下游或者同业的小型公司输出，提升其开发效率和稳定性，做得好的话也是双赢的。
感谢阅读，希望这篇文章能给你带来帮助！
