完成比完美重要

一 最小可用，快速迭代

最简可行产品是指可以先发布一个最简单的可行的产品版本，验证设计人员和产品人员的想法。

在开发一个新系统的时候，如果上市时间比较紧，那么一般会做一个最小可用集合的产品，优先实现产品的核心功能，保证用户的基本体验，然后逐步迭代开发新版本，补全缺失的其他地方。在这环节中，保证每个版本都形成闭环，然后一层一层添加功能，快速迭代。

好的架构是演化出来的，不是一次性设计出来的。在设计时，不是不顾以后，只看当下，而是想到系统以后要扩展，要先想到理想的系统是什么样子，为以后升级系统提前预埋好升级逻辑，然后一步步迭代到最终形态。

二 不要等待

在软件快速迭代的过程中，有些工作是互相依赖的。例如，开发人员要依赖产品人员的需求单，测试人员要依赖开发人员做好的系统，否则都无法进行后续工作。这时要想办法尽快推进工作的进展。把一些大需求的实现过程分解为几个小迭代步骤。这样几种角色的工作可以并行，而不是互相等待。还可以主动寻找一些迟早要做，但不互相依赖的工作，保证没有空闲的时间片。

还有一点是现有的服务和架构是否满足用户当前的需求，如果不能完全满足，那么可以满足百分之多少？

可以先发布一个让用户马上能咨询的版本，减少用户的等待，做一个六十分的产品。

如果一直等 App 的功能做完善，可能用户已经流失了。

在遇到一个好的产品机会的时候，要抑制一步到位的冲动。

长远来看，架构师要有一种延迟满足和逐步渐进的心态，在产品功能上分清主次，知道什么是最关键的功能，哪些功能是用户最看重的。如果几个功能或几种方案的优先级都被认为是最高的，那么和都是最低的也没什么差别，说明架构师没有彻底了解当前的方案。

三 接受不完美

给用户提供完善的服务，每个细节都做到尽善尽美，这是我们的目标，但在现实中，我们要给用户提供的服务不可能在每时每刻都是完美的，我们在心态上要接受有损服务。在设计架构的时候，也要考虑在各种极端情况下，如何尽力为用户提供服务。

1 分清主次

在相同的资源情况下，保障实现一个产品的主干逻辑，分支逻辑在资源不够的情况下给主干逻辑“让路”。

例如，加载一个聊天群的消息，首要的是加载消息内容和发送人的昵称。如果带宽没那么充分，那么发送人的头像可以延迟一会加载。否则带宽都被头像使用了，用户看不到消息，看清头像对用户来说意义不大。

2 自动降级

如果衡量出服务降级后用户可接受，那么可以在需要降级的时候，将服务降级。降级通常有两种，自动化降级和人工干预降级。一般人工干预降级是应对一些没有规律的突发情况。例如紧急故障等。在发生过故障的地方，如果规律确定，则可以实时自动化降级。自动化降级最主要的是要对标准有明确的量化，知道什么情况下需要降级，要降到哪些级别。

3 代价最低

为什么要提供有损服务？一定是某些情况造成系统不能正常提供服务——一般是资源不够，或者是外部依赖的资源、接口质量有问题，还有可能是故障导致的。

a 资源不够

资源不够一般是带宽、内存或计算资源等不足。这里要提前计算好一个大服务中每个小服务所需要的资源，当资源不够覆盖整体的时候，按照优先级给重要的小服务优先提供资源，等待资源恢复的时候，再逐步给其他服务提供资源。例如，当发现网络不好的时候，给用户展示的就是压缩比比较高的图片，如果用户网络带宽状态很好，那么就展示原始图片。

b 依赖资源质量有问题

对于外部依赖的资源、接口，我们很难控制好服务质量。这时要有完善的监控，能够及时发现问题。当出现问题的时候，使用一些默认值，或者明确的提示语提示用户。而且有时要有备选“通道”，发现一个“通道”有问题，就提示并引导用户到另外一个“通道”上去。

c 故障

在设计系统之初就要考虑系统各层的调用是否会出现故障。如果出现故障，那么最差的表现是什么，是否有方法将出现问题时的代价降到最低。一般的方法是发现底层调用返回了失败后，有一个保底或默认的值能够让整体顺利运行。