单体架构适用于中小型产品前期快速迭代验证

单体架构适用于中小型产品前期快速迭代验证。在座的很多也有研发同事，大家都很有经验，单体架构在中小型产品的前期还是适用的。随着产品的发展，之后就进入到我们经常讲怎样转型微服务的阶段。转微服务并不是说从一开始就必须要做微服务的架构，我们经常讨论这个设计的时候也会提到一个过渡设计的概念，这就是说从一开始就搭一个非常完善的微服务平台的话，其实是有些过度设计的嫌疑的。中小型产品的前期是一定要快速迭代并进行验证的，那么单体的架构会更适合一点。如果一开始就一股脑的要把所有的东西都实现，可能不太适合在微服务上面做很多的事情，转型微服务，其实是一个自然而然的事情。

　 第二部分是微服务架构下面的应用性能监控，在说到微服务架构优势的时候，我们说它的监控其实是越做越简单，但是当你的服务拆分的越来越细的时候，你第一反应并不是它越来越简单，第一反应一定是它更复杂了。因为原来你的系统在一个单体架构下面的时候，把系统分布式环境下面拆成多个节点也只是并列的几个节点，只要监控这几个节点就可以了。但是拆分微服务之后，每个微服务都会拆分出来10个、20个上百个点，第一反应一定是更复杂了，这种情况下如何快速发现定位问题？有成百上千个微服务的节点，应用端调用出问题的时候怎么知道是哪个节点出的问题？
　　 这时首先需要比较完善的fawu.ma.cn指标采集体系，把数据尽快的监控出来并进一步定位和发现问题。服务器数量激增之后，首先部署和管理上有些问题，另外一个是调用链可能比原来变的更复杂了，原来是在一个单体里边模块跟模块之间的调用而已，现在有可能是A服务调用了B服务，B服务可能又调用了C服务，最上层的应用出问题的时候到底哪个服务出了问题，这对我们监控也是提出了一个比较大的挑战。