面向微服务的架构并不是软件工程的圣杯。但是，对那些依赖于技术而发展的公司而言，如果能将该架构运用恰当，那么将会是解决这些公司所面临的大部分重要问题的完美方法。

弹性，可组合性以及灵活性都是面向微服务架构设计的关键原则。将这些原则烂熟于胸是一件非常总要的事情，否则，你讲错失一个完美的解决方案，并最终在将单块应用分拆到多台机器上遇到大量的问题。

不足之处 。

事无绝对，周遭也存在着一些针对面向微服务架构的诟病，大家都到了一些需要处理的问题，例如：延迟，可追踪性以及单块软件中并不存在的配置管理的问题。其中一些问题如下：

1网络延迟：微服务具有分布式的特性，从而无可避免的存在网络延迟。
2运维负担：更多的服务器也意味这需要更多的维护工作。
3
4最终一致性：在对一个事务性要求较高的系统中，考虑到现实的局限性，各个节点在某一段时间馁可能会出现数据的不一致（后续讨论）。

总而言之，工程师应该尽可能对该方法的利弊作出评估，然后根据是否满足相应业务需求来作出是否采用微服务的决定。

面向微服务的架构存在着一些需要被考量的特质。当软件工程师在编写单块软件的时候，受限与所构建软件的特性，很多问题都被忽略了。

举个demo，想象一下某个软件正需要一个发送电子邮件的功能，在单块软件中，我们在应用的核心部分加入该功能代码。更甚之会选择创建一个专门用于处理电子邮件的模块（听上去貌似是个好主意）。而现在，我们并不打算想这个庞大的软件组件添加功能， 而是选择了创建一个微服务。这是一个可以独立部署且可以独立版本化的专用服务。在这个案例中，我们忽略了一件事，即：在请求该新的微服务的过程中会产生网络延迟。 在前面的例子中，不管你采用哪种方式（单块方式亦或是微服务）来构建软件，并不存在任何严重的问题，举个例子，就算是丢失一封邮件，也不会因此到达世界末日。