需求确认完毕，开始开发了，技术架构评审要不要开？怎么开？其实，很多项目团队都会有犹豫。要么觉得项目很小，就不开了。要么流于形式，按照模板填写，搞成作业。
那应该怎么办？我们回到原点，技术架构评审解决什么问题。我觉得实现当下的需求当然重要，这里就不再展开。但解决未来的需求同样重要。
哪些是未来的需求，就是解决两类问题，一个是业务未来的可扩展性，一个是系统稳定性和可用性。总之，就是解决需求之外的非功能性需求的。这两点往往是我们容易忽略的问题。因此，我觉得如果项目对应的业务还会继续发展，就应该开技术架构评审。评审的形式不重要，解决这两个问题最重要。
先看第一个问题，业务可扩展性。就是业务未来会发展成什么样，短期会是什么样，长期又是什么样，这个过程大概多久。理解了这些，你就知道技术怎么去架构了。
比如很多人很苦恼微服务怎么搞，哪些要做服务化。我告诉你学再多原理都没意义，只有你对业务有充分的了解才会有答案。举个例子，如果做一个自营的电商，未来有可能发展为平台，那就要提前考虑，就要为店铺架构留出一定的空间。
第二个问题，系统的稳定性和可用性。依然需要根据业务的发展情况来考虑。比如，未来要做抢购，你就要提前预计可能的流量，来重新设计技术架构。
那么怎么开好架构评审？大家可以看到，架构评审就是解决不确定性，是业务的不确定性。了解这一点非常重要。所以，开好架构评审，需要你先对业务需求进行分析。找出近期和长期的业务变化点，然后设计出架构支撑的目标。比如业务可扩展点，系统流量的支撑点，由目标出发，设计架构。
另外，讨论的内容需要提前做好准备。都准备什么呢？就是准备能让大家方便讨论的展示文件。
什么展示形式更方便大家讨论系统扩展性呢？逻辑架构图可不可以？图中标注好未来可能的扩展点，说清楚这样的架构怎样支撑这种变化，代价如何。
什么展示形式更利于讨论系统稳定性和可用性呢？核心的流程图和系统架构图可不可以？要保证系统的稳定性，首先就是要把系统的各个服务环节分出轻重缓急。对重要的流程要标注出所有的节点，每个节点都要仔细考虑，这个节点是不是必须经过的节点，当出现问题的时候能采取哪些措施，能否能够降级处理等等。
同样，系统架构图中也要标注出，哪些是系统中的单点，是否需要做备份处理。当一个节点出现问题的时候，整个集群又怎么恢复过来。
提前准备好这些，我们在具体讨论中才能目标明确，效率高。
总结一下，架构评审需要开，会议之前先要分析业务，找出架构目标。架构目标决定设计思路，大家评审就是看目标能不能支撑，有没有更好的办法。
