最近断断续续花了差不多2到3周的时间阅读完由电子工业出版社出版的《金融级IT架构：数字银行的云原*架构解密》的这本书，作者是作者是网商银行技术编委会。
本书契合了当前银行业分布式架构转型趋势，内容是经过实践检验的领先技术介绍了网商银行IT技术架构演进路线，涵盖了分布式、单元化、弹性混合云、云原*多个基础架构领域，同时介绍了技术风险、安全可信、业务架构等多方面的技术实践经验。
对于这本书实际很早搜索云原*相关书籍的时候就搜索到，但是一看标题是金融IT架构方面的因此没有引起太多的重视，后面由华章图书赠阅后才有幸阅读到该书，读完以后有一种相见恨晚的感觉。
对于网商银行个人原来不熟悉，开始觉得奇怪为何网商银行能够写出该书，后面上网一搜索才了解到网商银行是由蚂蚁集团作为大股东发起设立的中国第一家核心系统基于云计算架构的商业银行。它作为银监会批准的中国首批5家民营银行之一，于2015年6月25日正式开业。所以网商银行服务小微企业本身业务量也很大，同时由于蚂蚁集团是大股东，因此在整个IT基础设施和技术架构搭建中采用了阿里，蚂蚁金服很大开源的技术组件和架构。或者说网商银行很大技术人员本身就是前阿里的技术专家。
因此网商银行技术编委会能够写出该书也就不奇怪了。
但是为啥是整个编委会而非单个作者，这部分覆盖的内容相当广泛，从IT基础设施架构，到云原*，到安全可信，到中台等。每一个单独的章节内容都有足够的深度，很难有一个人能够都多有细分技术领域都掌握到如此程度。
而且基本上每个部分的内容一看就是来源于IT架构搭建的一线实践所以，*括很多经验点的分享也来源于大量实践复盘，这就不是一般的技术书籍能够所以到的点了。
根据该书的内容简介我们也可以看到同样的内容说明。
介绍了网商银行成立至今的IT技术架构演进路线，涵盖了分布式、单元化、弹性混合云、云原*多个基础架构领域，同时介绍了技术风险、安全可信、业务架构等多方面的技术实践经验，我们希望和读者分享网商银行在金融级IT技术上做的独特探索，跟大家探讨数字化时代金融级IT架构的发展方向。
本书作者是网商银行核心架构师，深度参与了相关技术方案从前期设计到后期投产的完整过程，内容清晰且权威。本书以网商银行自身技术实践为主线展开，讲述的内容代表了领先的技术方向，相关技术经过了真实的*产环境锤炼，*含了网商银行技术团队独到的实践经验，书中阐述的核心技术荣获中国人民银行颁发的 “银行科技发展奖”二等奖。
这本书不仅仅是适合金融行业IT从业人员阅读，也同样适用于需要构建集团型大的IT基础设施和云原*架构的人员阅读。很多金融行业在分布式，高可用，弹性扩展，安全等方面的架构和实践经验积累完全适用于大型企业的数字化和云原*架构转型。
下面对本书的一些关键内容做一些关键点的整理，本书的一些PPT配图来源于本书撰写作者之一蒋易民的公共技术分享。
网商银行的三代架构演进过程
从这张图来看，网商银行主要经历了三代架构的演进。
第一阶段主要是基于云平台+分布式架构建立起来的。整个的部署模式是同城双活模式。到了2017-2018年的第二阶段，在同城双活的基础上需要建设一个异地数据中心，希望这个异地的数据中心在日常过程中能承载业务流量，能与杭州数据中心同时对外提供服务。在满足异地灾备要求的同时考虑提升整个IT基础设施的资产利用率，所以打造了单元化多活架构，它是一个三地五中心的部署结构。从2019年，网商银行开始关注云原*架构，*括开始引进一些产品，设计建设相关能力。在这个过程中，我们也建设了混合云弹性架构，具备了在两朵云之间调度资源的能力。
简单所以整个演进路线关键技术点为：
数据垂直拆分，数据水平拆分，分布式架构构建，云计算平台构建，单元化多活架构，弹性架构，弹性架构建设，混合云架构建设，云原*可信架构建设。
单元化架构
在这本书里面提到一个重要概念，即单元化架构。
每个单元是一个从流量层，应用层到数据层的完整，自治，独立的*态系统，能够为用户提供绝大部分服务，数据访问都尽量封闭在独立的单元内完成。因此可以将一个单元部署到任何一个地域，同时单元和单元之前能够互为备份。
大家看到这个的时候可能会联系到分布式和微服务。
因为我在谈微服务的时候也经常在强调重点是单体到微服务的拆分，每一个微服务都实现从数据层，逻辑层到应用层，从需求，设计，开发构建，编译部署的独立自治。但是这些都是在谈软件层面的单元化。
而单元化架构目标是实现软件层面+硬件层面的共同单元化。有点类似多年前流行的一体机概念。软硬一体化单元化更加方便了每个单元的跨地域，多数据中心移植能力，也进一步增强了IT基础设施层面的高可用性和冗余。
从弹性计算到云原*
在传统PaaS平台的时候也谈弹性计算和资源动态调度，但是传统PaaS很难做到完全灵活，自动化，完全自动伸缩的弹性架构能力。
弹性一方面是自动化，一方面是要实现既可扩展又可收缩。
网商银行从诞*起，IT系统就构建在私有云上，IaaS基于阿里云专有云底座建设，PaaS基于蚂蚁集团的金融云构建，天然拥有了分布式计算能力。并具备了金融级别的安全，高可靠，高可用能力。
云原*技术*括了微服务，容器化，不可变基础设施，声明式API，服务网格等。云原*架构是基于云原*技术的一组架构原则和设计模式的*，最关键的点就是把一些业务处理逻辑中非功能性的代码剥离出来，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、可观测性、灰度等）。
从上面图可以看到，传统架构中任何一个代码逻辑都*括了业务代码，非功能性代码和第三方依赖。而在云原*架构下，希望的是业务和技术分离，业务功能开发人员只开发业务功能代码，而平台类开发人员负责各种非功能性需求和可观测性的实现。
大量非功能的特性，*括弹性、容量、安全可观测性、灰度等都会逐渐下沉到底层的基础设施，特别像高可用能力、容灾能力、容量保障、安全特性，还有一些可运维的特性，逐渐让基础设施去接管。这种情况下可以看出，在我们在部署上会发*的一些变化。从图的右下角看到，容器会进行进一步的拆分，拆成应用一个进程，边车（sidecar）一个进程。
在这本书读完后给我的另外一个最大的感受就是。
在传统IT架构转型，微服务化，和云原*技术发展过程中。为了实现弹性和灵活扩展，实现分布式，实现去中心化，ServiceMesh服务网格应用势在必行。
特别是在通过容器云和Kurbernetes实现了容器资源的调度编排，不可变基础设施后，为动态的下发边车代理，将Sidecar和业务容器打*到一个POD进行管理成为了可能。这也大大地推进了Mesh网格化技术的发展。
在彻底的网格化后你会看到了，除了南北流量还需要上层的负载均衡设备来解决外，其它问题都可以通过边车代理和去中心化方式来解决流量分配和路由，对接口服务和流量的安全，日志，限流熔断等各种治理能力。
网商银行早期也经历过富容器，这种较重，*含了所有的应用发布部署需要的依赖，不限于一些关键的RPC、消息、数据库等SDK。最小的部署单元也是一个容器，在云原*里做进一步划分。
容器会区分为APP的容器，跟Sidecar 的容器。根据现在的实践来看，主要是*含Service Mesh里面MOSN的容器，还有DBMesh的容器。这两个容器解决的是 RPC、消息，还有数据库跟缓存层面的转发。
这种模式有一个最大的好处，就是MOSN跟DBMesh可以独立演进，即可以不需要在上层业务容器配合的情况下，自己完成一些升级跟发布。
在Mesh化架构里面，实际网速银行分为了两个不同的Sidecar，其一是解决东西流量和服务治理的MOSN，另外一个就是DBMesh代理。
DBMesh代理是很重要的一个思路。
简单来说就是在数据库分布式，或数据库进行了水平和垂直拆分后，传统的架构逻辑思路是在拆分出来的各个单元上面在增加一个DaaS统一数据访问层。但是DaaS层本身的部署又是集中化部署的，即所有的到底层数据库的流量全部要经过DaaS层的APP服务器，那么DaaS层本身又变成了一个中心化的节点。
因此最佳方案应该是DaaS层的能力作为一个独立容器Mesh化到各个POD组里面去。
流量隔离和流量调拨
云原*架构的核心价值是可以实现流量的精细化隔离。
在整个架构彻底Mesh化后，可以看到在Sidecar边车代理处可以很好的处理对流量的路由，流量的隔离和精细化控制能力。
基于新的云原*能力，在流量转发的过程，可以在流量通过MOSN边车代理时进行标记，让它路由到指定的一些容器上，就可以做到不同业务请求下，它会路由到不同的容器集群里，业务之间的相互影响就得到进一步降低。
最典型的是*产遇到的热点账户问题，很容易导致全行的交易抖动。如果我们可以识别不同的业务所导致的热点，可以做到有效的隔离，发*热点时不会影响到非产*热点的其他业务场景。
在新的云原*架构之下，基于mosn可以打造更细粒度流量调拨，从数据中心层面进一步下沉到单个应用级别。可以找一些不敏感的应用服务先切流，避免影响到关键业务内容。
在没有进行Mesh化前，如果仅仅是通过负载均衡设备或*来做这么精细化的流量隔离往往很难实现，这也是Mesh化带来的一个另外一个关键能力。
从全链路压测到混沌工程
对于云原*架构的复杂性，引入混沌工程是一个必然趋势。
2018年，混沌工程（Chaos Engineering）成为CNCF的一个新的技术领域。
对于混沌工程部分CNCF基金会将其纳入到可观测性部分。在2020年8月完成了可观测性技术调查，最终用户社区的成员被问及他们评估、试验并随后采纳了哪些可观察性解决方案。对283个数据点进行排序和复查，确定最终位置。
混沌工程的一些关键点。
其一就是混沌工程不是仅仅在测试环境做，而是在*产环境直接模拟。也就是说测试环境难以完全模拟*产环境，那么就需要在*产环境进行节点故障模拟，也确认整个IT架构在*产环境的稳定性。
其二就是真正融合了业务并发性能测试和可靠性测试两方面的内容。而在传统测试中这两者往往是分离的，很难在测试环境中完全模拟。
其三就是故障模拟本身的不确定性，第一就是故障本身产*的不确定性和随机性，第二就是各种故障本身场景组合的不确定性。
云原*下的分布式架构复杂度，引入混沌工程是一个必然趋势，就像我在前面谈云原*和微服务的时候谈到，引入ServiceMesh来进行微服务治理也是必然趋势。
混沌工程当前是一个蓬勃发展的技术领域，也越来越受到重视。也是当前应对分布式架构复杂度下提出的一套切实可行，严谨的工程实践原则，方法和工具。混沌工程基于反脆弱的思想，模拟故障只是手段，而核心目标仍然是提升系统的稳定性和可观测性，及早地发现各种风险，并进行优化解决。
任何一个*产的业务系统，都不应该是出现故障后的问题驱动，而应该是主动发现，主动防御的风险驱动机制。这就是混沌工程在云原*架构下的巨大价值和作用。
这本书对全链路压测做了简单的介绍和方法实战，但是从全链路压测逐步升级到混沌工程方*，是应对云原*架构复杂性的一个必然转变。
对于云原*架构，实际在原来的文章我也谈了几个关键的技术点能力值得深入研究，其中主要*括了如下内容。
- 混沌工程和可观测性
- ServiceMesh和去中心化服务治理
- 高度灵活自动化的弹性扩展架构
- 分布式中间件和分布式事务
- 一体化研发运维平台和DevOps
- AIOps
- 流量治理
- 安全可信架构
以上内容将是云原*架构和技术发展，并逐步走向成熟的关键内容。
当然这本书也有一些不足，由于本身是处于多个技术团队，多人的作品，感觉每个章节讲述的内容之间的逻辑关联关系存在不严谨的情况，同时也会在不同的章节出现描述同样内容的情况。这是多人合著情况下经常会遇到的问题。
但是还是要说明下本书和简单拼凑还是有差异，瑕不掩瑜，整体的框架内容还是完整的，很多实践的内容和经验分享都值得仔细学习并借鉴。再次推荐该书。特别是中大企业面对数字化转型，云原*的IT技术总监和架构师阅读。
