技术架构评审

　架构评审要不要开？怎么开？其实很多项目团队都会有犹豫，要么觉得项目很小，就不开了，要么流于形式，按照模板填写，搞成作业。

　　那应该怎么办？我们回到原点，技术架构评审解决什么问题，我觉得实现当下的需求当然重要，这里不再展开，但更重要的是解决未来的需求，就是解决两类问题，一个是业务未来的可扩展性，一个是系统稳定性的可扩展性，总之就是解决需求之外的非功能性需求的，因此我觉得如果项目对应的业务还会继续发展，就应该开技术架构评审，评审的形式不重要，解决这两个问题最重要。

　　先看第一个问题，业务可扩展性，就是业务未来会发展成什么样，短期会是什么样，长期又是什么样，这个过程大概多久，理解了这些，你就知道技术怎么去架构了，很多人很苦恼微服务怎么搞，哪些要做服务化，我告诉你学再多原理都没意义，只有你对业务有充分的了解才会有答案，举个例子，如果做一个自营的电商，长期也不会发展为平台，那就没有设计店铺架构的意义。

　　第二个问题，系统稳定性的可扩展性，依然需要根据业务的发展情况，比如，未来要做抢购，你要预计可能的流量，来重新设计技术架构。

　　那么怎么开好架构评审？大家可以看到，架构评审就是解决不确定性，是业务的不确定性，了解这一点非常重要，所以开好架构评审，需要你先对业务需求进行分析，找出近期和长期的业务变化点，然后设计出架构支撑的目标，比如业务可扩展点，系统流量的支撑点，由目标出发，设计架构。

　　总结一下，架构评审需要开，会议之前先要分析业务，找出架构目标，架构目标决定设计思路，大家评审就是看目标能不能支撑，有没有更好的办法，至于什么形式并不重要。