成本
都是钱惹的祸
邓爷爷说过一句话，“黑猫白猫，抓住老鼠就是好猫”。好的架构也同理，在软件系统的整个生命周期里面，系统便于理解，易于修改，方便维护，能轻松部署，那就是好的架构。一言以蔽之，最大化程序员的生产力，最小化系统的运营成本。
软件架构不只是需要考虑开发成本，也需要考虑部署成本，运行成本以及维护成本。
对于一个小于5人开发的单体系统，是不需要一开始就设计一个上层建筑来进行限制的，人与人之间的面对面交流效率更高，而如果一个系统涉及多个团队，多个组件，那么就需要将系统划分定义清晰的组件和可靠稳定的接口，否则交流成本急剧提高，开发工作就没法进行下去。
对于部署来说，目标永远都是一键部署，但是对于单体系统和微服务架构系统来说，实现这个目标的难度是天壤之别的。
而对于运行依赖的环境来说，因为摩尔定律，硬件成本反而是所有成本中最低下的，只要不是操作系统层级的代码，性能优化永远是排在最后的，硬件能解决的问题，尽量先不考虑软件的优化。
软件系统的各个方面综合来看，维护所需要的成本反而是最高的，修复一个现场故障带来的成本，十倍甚至百倍高于修改代码本身的工作量。所以好的架构需要重点考虑定位问题的难易性，新增功能的容易性，降低修改过程引入新问题的可能性。
重复
本章节中对重复的见解出乎我的意料。平时编码过程中，一直是号召整洁代码，那么对于重复代码就是一件需要尽力消除和减少的事情。重复本身会引入很多问题，比如结构不清晰，比如修复故障的时候，可能只修改了一处，另一处重复代码未被修改等，sonar系统中一个技术债定义就是代码重复度。
不过本书认为，如果可以预料随着时间推移，重复代码本身会各自演变，直到最终完全不同，那么尽早让代码分离开反而是更好的选择，可以避免同一代码兼容不同场景造成的复杂度急剧上升。
解耦
组件的设计原则是高内聚低耦合，如何解耦就是软件架构中需要更多考虑的事情。根据不同层次，解耦可以分为下面几种：
源码解耦：源码之间是通过函数调用来产生关系，如果没有一定的规则限制，那么这个调用关系很可能会出现你中有我，我中有你的网状关系。所以在源码层级就需要进行模块划分，进行接口定义，减少模块之间的耦合程度。
部署解耦：对于单进程软件来说，一个模块的变化不需要另一个模块重新编译，就说明解耦不错，对多进程软件来说，需要考虑进程间通信（socket或者共享内存），一个进程重新部署不需要另一个进程重新构建或部署，那么就是成功的部署解耦。
服务解耦：当组件之间的依赖降低到数据结构级别，只通过网络数据包，也就是我们常用的restful接口来进行链接，这样每个部署单元都可以认为是独立的个体，微服务架构即使如此。
三种层次的架构无所谓高低，好的架构是允许一个系统从单体结构开始，以单一文件的形式部署，然后逐渐成长为一组相互独立的可部署单元，甚至是独立部署的服务或微服务，最后还可以根据情况的变化，允许系统以单体的结构部署，也就是可分可合的状态。
网友评论