我们常说舍得是有舍才有得。作为架构师经常要做取舍。

在性能篇中我们说为了高性能会牺牲一部分一致性的要求，还有哪些地方需要取舍呢。

一、面面俱到还是只做符合当前案例的设计？

我们讲做事面面俱到是很棒的，但是如果应用场景不匹配则资源是浪费的。精益创业思想一般提倡产出 MVP 最小可行性产品。如果一刀切用上一些看起来高大上的成套解决方案，你将遇到的挑战是没有其他人能深刻理解，容易执行跑偏；相反在当前架构基础上设计一版小幅改动版本，更容易成功。

二、松耦合还是紧耦合？

单体应用 VS SOA VS 微服务，耦合度越来越低。减少了整体故障率，但管理的节点变多了，降低了运维成本和开发成本，增加了团队人数的投入。一个人把产品设计前后端开发测试运维都做了，一个单体应用很合适；需要多人协作的时候拆的越细，引入的管理成本越高。

所以研发团队规模到了一个量级以后就需要逐步向松耦合的架构迁移了。这里要强调的是，如果业务规模扩大了而团队规模并未扩大时要谨慎考虑松耦合，试想一个人维护数十个微服务的时候必然会顾此失彼。

三、全面推广还是准入管理？

当你开发出了一个很牛逼的组件，想要让团队接入时，开个会给大家培训完所有人都掌握了，接入成本非常低，你的工作并没有结束，找业务团队多探讨一下使用场景，切忌滥用，好钢用在刀刃上。举例：很多人觉得缓存是银弹，多级缓存设计更好，你开发了一个性能非常棒的多级缓存组件，而且考虑了缓存实效风暴、DB击穿等问题，希望大家都来使用，但要考虑调用方的量级是否合理，毕竟业务研发觉得可以用缓存的地方很刁钻，很可能导致你的缓存服务命中率极低，造成浪费。再次注意缓存的数据应当是有失效时间的读多写少的热数据，读写都很少的数据别考虑性能了，放到文件存储里吧。

通过三个点抛砖引玉，在做架构的路上希望与大家交流心得体会。