在了解引入微服务架构的时机之前，架构设计时一般需要遵循的三个原则。
架构设计三个原则
架构设计一般需要遵循以下三个原则：
- 合适原则：合适优于业界领先。
- 简单原则：简单优于复杂。
- 演化原则：演化优于一步到位。
合适原则
我们一般都有很强的技术情节，做架构方案时，总想着挑战自己，做一个很牛的架构，但如果设想超越了现实，最后很可能会失败。
即使我们的设计再好，能为公司打下很好的基础，但公司的实际环境如何？能否很好的落地？如果没有那么多人，却想干那么多活，肯定失败。
优秀的架构其实都是逼出来的，业务发展到一定阶段，量变导致质变。没有那么强大的业务场景支撑，失败的概率非常高。
简单原则
很多人评价一个设计方案水平高低时，很喜欢看复杂度，越复杂的系统，出现故障的概率越高。
应谨记KISS（Keep It Simple, Stupid）原则，大多数系统的设计应保持简洁和单纯，而不掺入非必要的复杂性，这样的系统运作成效会取得最优。
演化原则
对于建筑来说，永恒是主题，对于软件来说，变化才是主题。
架构设计时要时刻提醒自己不要贪大求全，或者盲目照搬大公司的做法，应认真分析当前业务的特性，明确当前业务的主要问题，设计合理的方案，快速落地以满足业务的需要，然后在运行过程中不断完善架构，不断随着业务演化架构。
什么时候引入微服务
微服务架构虽然看起来非常美好，但是也是有很大附加成本的。
通过上图可以看到，横轴是复杂度，纵轴是生产力。当软件的复杂度很低的时候，单体架构下的生产力是要高于微服务架构的，但随着复杂度的不断增加，无论是单体应用还是微服务应用的生产力都会下降，只是微服务架构的下降会相对缓慢一些。
因为在微服务架构中，我们的系统是由很多的小的服务组成，每一个服务都很小，相对简单，技术栈也很独立。这样做局部的变更也会更加容易，随着系统复杂度的不断增加，微服务的优势也就慢慢地体现出来了。
怎么引入微服务
在合适的项目，合适的团队，采用微服务架构收益会大于成本。微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。需要避免为了“微服务”而“微服务”。
Martin Fowler（马丁·福勒）提出的单体架构优先（Monolith First）的思路，我们可以了解一下：
不推荐一开始就全盘直接使用微服务架构，因为微服务需要前期基础设施的投资，复杂性很高，如果对问题领域并不是很理解，一开始用微服务，很难去划分服务的边界，生产力反而会比较低，而且花了很大精力进行开发，产品并没有被市场验证过，有可能会失败，所以这个选择风险会比较高，所以推荐的是单体架构优先。
先从单体架构运用做起，这样成本低，团队成员也比较少，无须太多研发投入，就可以快速迭代并交付一些基本的功能，这样也可以赢得更多的时间去探索业务领域的复杂性，对业务领域的边界会有更深入的理解。可以考虑引入部分合适的微服务架构，原则是边界已经很明确的小范围领域，或是对已有系统进行改造或，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。
随着应用越来越成功，用户越来越多，系统复杂度越来越高，就会出现单体架构应用和团队规模之间的矛盾，生产力会随着业务复杂度逐渐降低，这时再逐步的进行微服务化的拆分效果会更好。