再谈传统企业IT架构转型(11.13)

在11月7日文章我提到，不论涉及到多少的技术和关键词，我们可以看到传统企业的IT架构转型实际上核心就三点。分别是业务层，技术层面和管理层面。需要这三方面高度协同并形成一个整体，才可能真正实现平滑的迁移和过渡。

1. 业务层面：核心能力中台构建，也可以说是微服务模块的划分和API接口服务识别

2. 技术层面：各种技术的融合，协助转型的支撑平台建设，也就是我们说的DevOps支撑平台

3. 管理层面：研发管理过程的改进，从最初比较重的CMMI转到敏捷管理方法论和过程实践

在我们谈IT架构转型的时候，一定要从实际的场景和问题去分析，不是为了新架构而架构，这个也是我一直强调的重要观点。而对于问题本身我们又要理解到实际上包括了两点。

1. 当前已经面临的问题：类似系统性能问题，运维问题，变更处理和上线及时性问题，安全问题等。

2. 已经发现趋势的风险：当前还没有转变为问题，但是根据历史数据和用户使用情况已经发现关键风险。

当前已经面临的问题

对于一个传统的IT应用架构，我们可以来看下可能存在的当前面临的问题，这些问题既包括了业务层面，也包括技术层面，还包括了管控治理层面。但是最终都可以归集为对于IT系统支撑业务需求和业务目标的能力变弱，或者说已经到了无法支撑的程度。

一个IT系统的开发一定会涉及到相关的技术架构选择，包括了技术平台，开发框架，开发语言，开源组件使用等，而这些平台或框架随着时间推移本身也在不断升级，还有些干脆就是不再提供技术支持。这些都需要我们对已有的IT系统进行全新改造或升级。类似我们原来用VC++开发的业务系统，到了11年都还在用，但是微软已经不提供支持，只能够逐步将功能移出。还有就是开发框架和语言，数据库的版本在不断升级，旧版本不再提供支持，这些也需要我们定期对业务系统进行版本升级改造。

传统IT系统是单体应用，虽然单体应用本身可以集群化部署，但是很多时候对于数据库往往并不会使用RAC集群，或者说数据库本身并没有扩展能力。这个在业务系统发展到后期，在用户数，业务数据量，并发量都不断增加的情况，带来的明显问题就是性能问题。而这个性能问题也是业务系统不断持续优化的关键，包括了数据库集群化升级改造，历史数据清理和迁移，本身的SQL语句和代码优化等各种方式，最终都是为解决性能问题。当以上各种方式和努力都不太起作用的时候，往往就涉及到真正开始将单体应用进行逐步拆分和剥离。

其三，IT系统的可运维能力下降的了，当发现问题或故障的时候查找原因很难，可能大半天都定位不了具体的问题究竟出在哪？其次就是系统原始架构就部署完全冗余化设计，导致出现问题后的系统恢复时间也变慢了，有时候即使重启整个应用也无法恢复，这些都将直接影响到具体的用户使用和需求满足。

其四，单体系统模块紧耦合导致敏捷响应业务需求的能力变慢了，用户提交的需求变更往往要花很久的时间才能够变更完成并最终上线发布。其原因就是整个单体系统随着后续功能的叠加变得越来越复杂，模块间的耦合性也是越来越强，即使最简单的一个变更可能都涉及到代码多处的改动，而且代码和代码之间还有千丝万缕关系，稍不注意就可能影响到其它能够正常使用的代码。还有些应用模块间的集成还不是走的标准的应用层API接口，而是直接使用的数据库Dblink连接，这个更加导致了一个数据库究竟有多少外围在使用，究竟使用了哪些数据库表完全不清楚，任何一个数据库的表结构变更往往都影响巨大。

已经发现趋势的风险

什么叫已经发现趋势的风险，简单来说就是随着用户数，业务量和并发量的增长，你已经能够明显感觉到系统在变慢，但是还能够忍受，你预估和测算这个趋势会发现到了哪个时间节点可能IT系统的能力就无法满足。那么你就必须提前去考虑这个问题，并对相关的架构和技术点进行优化改进，而不是眼睁睁的看着问题变化为风险。

系统可扩展性能力弱是最容易发现的风险，即随时业务量增长你发现系统没办法做到完全的平滑扩展，这里面包括了数据库，也可能包括了应用服务器集群，你会发现由于没办法做到扩展，等数据量和并发量一上来一定会出现应用性能问题和瓶颈，这个时候你就要早点去考虑架构优化和升级。这个升级一样两个方式，一种是已有架构优化支持扩展性，一种就是彻底的微服务化拆分。

其次就是前面说过的可运维能力变弱，IT系统上线了，但是你发现对IT系统的运维和监控能力没有跟上，导致出现问题后查找和定位故障相对的耗费时间。那么这种时候一定要考虑对系统进行优化，这个优化不仅仅是包括了实施相应的IT监控和APM系统，更加重要的是对已有的系统代码进行优化，包括了相应的日志记录，日志采集，性能数据收集等，关键异常日志记录等，这些都是方便你后续快速的定位故障和问题。

系统变得没法维护了，也是我们经常会遇到的问题，代码间耦合性强，而且逻辑混乱，修改代码的时候往往摸不着头脑，相关的变更也是到处乱加，到了这个时候一定要考虑对代码进行优化和重构，理清代码逻辑。所有开发人员都要意识到代码的可维护性是代码的一个关键非质量属性。