架构过度设计与系统重构

字数 1532阅读 541评论 0赞 2

内容摘要：

应用上云需回归业务，非必要不重构；重构需考虑业务变化、问题、维护和代价；架构设计应以业务为中心，避免过度设计。架构是可持续可进化的技术约束和原则集合。

当前摘要为AI生成

最近跟一个客户聊起应用全面上云的事情，过程中涉及到了大量原有单体应用如何上云的问题。单体应用上云到底是直接迁移和还是重构，这个问题不管是在哪儿都是不是一个小 事儿，都需要审慎的思考。沟通下来很有感慨，把心得体会记录下来，以备咨询！

一、我们到底要解决什么问题

首先我们要搞清楚，我们到底需要解决什么问题。我们所在的组织到底是如何理解数字化和数字化转型的。从信息化到数字化的过程中，我们基本会从三个阶段一路发展过来：

1、概念导入期：在这个阶段我们会尝试理解和接受数字化的概念，我们会在IT基础设施这块“补短板、强弱项”， 但是非常容易陷入一个误区，那就是过分放大IT和技术的重要性，会认为数字化转型就是大干快上新技术和新平台、新应用，陷入技术的TCO泥潭里面 ；

2、能力成长期：随着基础设施的能力提升，我们开始深入考虑IT与业务的关系，IT开始从应用和数据两个层面跟业务产生深度关联，通过应用和数据能力的提升去探索新型能力建设。 在这个阶段始终有一个问题在困扰我们，到底是IT引领和推动业务创新发展，还是IT支撑业务发展 ；

3、价值呈现期：在理顺IT和业务的基础上，尘归尘土归土，我们不在纠结先有蛋还是先有鸡的问题。数字化转型的价值呈现，始终会通过业务的提升表现出来，我们需要面对的始终是业务如何发展。 就算云计算一样，云计算的价值就是最终大家会忘掉云的存在 。

通过上面对数字化的剖析，我们就会发现，我们关注的重点和核心永远都是业务的concern。因此对于应用上云过程中暴露出来的问题，就很容易理解了， 单体应用是直接迁移上云，还是做架构重构，这个问题必须回归到业务层面 ，一切以业务安全、稳定、敏捷、持续运行为第一要务。

二、非必要不重构，重构谨防过度设计

明白了数字化的发展历程和我们的关注点，我们应该形成一个行事原则，那就是非必要不重构，简单来说别给自己找麻烦。系统重构的必要性原则都有哪些呢：

1、 业务是否发生重大改变 ：业务逻辑和流程已经发生了重大改变，现有应用系统已经无法适应业务的发展，或者是说业务部门的认知已经远超IT实现了；

2、 是否存在关键和致命问题 ：现有系统有明显BUG，在现有条件下无法解决或者需要付出极大的成本，这个成本已经接近或者超过重构成本了；

3、 系统陈旧无法维护 ：系统老旧，供应商无处可寻，关键文档缺乏，维护人员不足，系统谁也不敢动。这种情况下，如果业务逻辑清楚，非常有必要重构。长痛不如短痛；

4、 接口和依赖关系是否清晰 ：在重构之前还有一个关键问题需要解决，那就是系统对外的所有接口和依赖关系是否都搞清楚了，如果没有，我劝你千万别动。

如果以上问题都搞清楚了，重构还是可以考虑的，关键是成本和代价必须在可承受的范围内。

架构的过度设计是怎么回事呢？这事其实很大程度上，有技术人员炫技的成分在里面。

嫌弃MySQL太土，非得上商业数据库，先单库不时髦，非得弄分库分表；嫌弃All in one设计太臃肿，非得搞微服务，明明调用关系很简单，非得搞解耦；数据访问逻辑很清楚，非得在数据和应用之间加一层代理；觉得虚拟机不先进，非得上容器；嫌弃原有代码不漂亮，非得重写的才香；嫌弃原有技术栈太旧，说出去丢人；不喜欢A语言编写的程序，非得觉得B语言才时髦。

大家别笑，上面这些问题每时每刻都在发生。 技术的选择和架构的设计没有绝对的对与错，适合的才是最好的 。过度设计劳民伤财而且后患无穷，我们始终都要以业务为中心，以持续发展为目标。

最后跟大家探讨一个问题，什么是架构？

我觉得，架构是在可调度的资源范围内，以实现某种特定需求为目标的，一个可持续可进化的技术约束和原则集合。

单体应用架构设计

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

架构过度设计与系统重构

添加新评论0 条评论

文章目录收起目录

作者其他文章

相关文章

相关问题

相关资料