6、软件架构与开发策略解析

软件架构与开发策略解析

在软件系统的开发与演进过程中，诸多因素影响着项目的走向与成果。从架构选择到开发方法的运用，每一个决策都至关重要。

1. 决策与架构思考

决策应依据服务水平要求来进行。团队不应过快确定解决方案，因为延迟对架构某些细节的决策往往有好处。例如，即便团队认定微服务架构是必要的，延迟引入由计算网络分隔的服务，能让团队专注于实际业务驱动因素，而非过早应对分布式计算的开销。

2. 单体架构并非必然糟糕

过去几年，“单体”和“单体式”在软件领域有了负面含义。但多数单体遗留系统陷入“大泥球”状态，不意味着这是必然结果。问题不在于单体架构本身，而在于架构中的混乱部分。

单体架构指整个应用或系统的软件存于一个能容纳多个子系统的容器中，通常包含应用或系统的全部或大部分子系统，具有自包含性。其内部架构可使不同子系统的组件相互隔离，也能提供子系统间的通信和信息交换方式。

即便最终系统架构是微服务架构，系统以单体架构起步也有优势。子系统间无网络分隔可避免早期不必要的问题，且使用单体架构能在易于实现紧耦合时展示对子系统间松耦合的承诺。若计划转向微服务架构，也能检验实际的耦合程度。

3. 微服务并非绝对良好

“微服务”的定义多样，有认为不应超100行代码，也有主张400行或1000行的。这些定义存在问题，“微”常暗示大小，但含义模糊。

以微处理器为例，它将CPU功能集成在一个或几个集成电路上，且微处理器的限制通常基于用途设定，而非特定的集成电路或晶体管数量。比如，28核的至强铂金8180有80亿个晶体管，而1971年的英特尔4004仅有2250个晶体管，它们都是微