架构设计及演化过程的思考

好久没有写文章了，今天的文章主要想记录一下自己这段时间架构设计和架构演化方面的一些思考，作为自己的架构笔记。

最近忙的一个项目，由于涉及多模块，而且需求方面考虑模块的可插拔，还要尽量考虑单独部署模块作为单独后台使用的可能，决定采用微服务架构。对于微服务架构，之前只是在有限的简单项目中尝试使用过，这次项目规模较大，所以遇到的问题也很多，期间架构也做了各方面的调整，结合开发的意见也做了必要的让步，这里做一个简单的总结。

1. 百家争鸣，迎接改变

一个项目初期的架构设计好了，不代表不需要调整，随着软件流程的启动，后续环节都会有各种各样的问题倒逼架构调整，这时候，要以开放的心态听取相关方的意见，结合多方意见并结合对项目整体理解后，做出决定，如果架构需要调整，要及时广而告之各个相关方，避免架构层面的问题导致后续的开发出现大的风险。

2. 把住底线，绝不妥协

上一条说了，我们要广泛采纳各方意见，但是不代表我们没有自己的判断，作为最后对方案拍板的架构师，应该从全局考虑问题，各相关方的意见难免都有自己的利益点，比如产品经理希望做出来的产品高大上，开发希望自己的开发工作简单，不同编程语言和生态的开发者都希望以有利于自己的最简单的方式来实现功能，后期维护则希望能够便于排查问题，便于修复问题。这个时候架构师需要有自己的判断，找到排除任何单一立场方面的利益点，做出最中庸和受益面更广泛的决定，毕竟各个相关方看到的只是项目的一个点，而架构师需要掌管的是从需求到上线以及后续维护整个产线的问题，还要适当的定出做出项目或者产品后，后期演化的方式和方向。

3. 架构模式多样，针对不同的情况

微服务架构作为主架构模式，但是不排除在遇到一些特殊问题时，结合其他的架构模式。架构模式类比于设计模式，可以组合。针对需要对接不同设备平台的问题，采用了适配器模式；单个微服务开发都是严格遵循分层模式；所有微服务之间的组织采用了多层模式；后期识别出来一个额外的目标，系统应当能够使得开源贡献模式得以实现；对于后续的一些需求，不可避免的还要采用发布订阅模式。所以，整个架构是多重架构模式的组合，针对不同问题，要能够识别出模式或者发现设计自己的模式。

4. 架构中预留一手

所谓的预留一手，实际上就是我们项目或者产品的“遮羞布”。作为架构师，需要权衡项目进度、开发人员的承载力、运维人员工作负担、项目工期等多方面的因素，不可避免的，架构中会有很多的让步，这些让步可能会导致后期的一系列问题的产生，其他人可以按照自己的喜好作出妥协，但是架构师作为系统质量属性和安全性属性的责任人，应当在妥协前权衡妥协点的影响，作出有限度的妥协，去设想万一出现问题的最简单补救方案，在开发中，协调开发人员，作出适当的让步来配合我们。毕竟万一出现问题，相关方都是有责任的，我们能以最小的代价作出响应，给出一定的弥补方案，对各方都是好的。

总的来说，架构师是对整个项目或产品的“生命”负责的人，我们要考虑项目或者产品在各个年龄段的问题，有时候需要想到的问题和情况可能就会更多一些，在做架构调整时会有保守的一面，但是这是全局把控问题的需要，因此常常被人误解为固执，但是，这可能就是架构师应该有的一些固执吧，时间会证明一切，坚持正确的，当未来你预测的问题出现的时候，你又很快的解决了问题，大家觉得你是预言家，但是此时我们心里清楚，我们不是预言家，我们可能只是提前看到了别人没看到的或者忽视了的可怕场景，而我们需要平时把这个场景在头脑中演练了多次，想到各种应对方案，我们时刻都在为这类事情做准备，希望这类事情带来的影响小一些，解决问题快一些，大家的技术债务少一些，开发的工作更加轻松有趣(做点新东西，学点新技术)一些。

上善若水，水善利万物而不争，处众人之所恶，故几于道。