架构的进化应该怎么走？

作为一个没机会做大型架构设计的老码农，瞎想一些架构进化。

现在很多时候架构设计其实很简单，好功能很多，做的也有点成熟，所以觉得想要就抓个过来用。微服务、分布式缓存、日志采集、Docker、自动化部署，统统都是好东西，用起来美滋滋。

不过我一直觉得，假如真的变成这样，其实只是变成了中间件使用者。

做一个架构设计，首先得有一个明确的目标和步骤。架构进化的首要目的是什么？要解决这个问题，我们现在的阶段是怎样的？要按照什么步骤去达到目标？

举些例子。
比如公司现在处于初创阶段。那首要目标可能是要快速验证业务。那这时候，你一大堆分布式的服务上来，然后又搞了很多机器，各种中间件。也许公司业务还没做起来，钱已经烧的差不多了，而且实际业务代码还没写几行呢，都在做服务拆分。

不过这个例子可能比较极端。
假如说一个公司到了中级阶段。微服务也有了，缓存也有了，日志系统也有了，自动部署也有了。这时候应该搞什么呢？猛一看呢，常规操作都可以，但是可以选的方向也有很多。有的公司觉得运维效率不够，所以上k8s，上云服务。有的公司觉得业务质量不足，所以上各种流程，上代码review平台。有的觉得公司业务连续性不足，所以上各种主备、集群、多活。

但按照我的想法呢，其实这些架构设计的统一问题在于，都是“觉得”。真的是如何，其实很多架构师都并不清楚。为什么呢，因为没有数据。
当你清楚目的以后，就应该去假设数据驱动的平台。
通过目的，去数据里面找到证据，才能去修改。修改好了以后，你还得通过数据去验证、去监控效果。
这个其实就是所为的闭环、反馈环。

结合目的，引进反馈，才是架构师应该去做的事情。