对于单块架构的系统，初始的技术选型严重限制将来采用不同语言或框架的能力。如果想尝试新的编程语言或者框架，没有完备的功能测试集，很难平滑的完成替换，而且系统规模越大，风险越高。基于微服务架构，使我们更容易在遗留系统上尝试新的技术或解决方案。譬如说，可以先挑选风险最小的服务作为尝试，快速得到反馈后再决定是否试用于其他服务。这也意味着，即便对一项新技术的尝试失败，也可以抛弃这个方案，并不会对整个产品带来风险。
该图引用自Martin Fowler的Microservices一文
独立测试与部署
单块架构系统运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署。 而对于微服务架构而言，不同服务之间的打包、测试或者部署等，与其它服务都是完全独立的。对某个服务所做的改动，只需要关注该服务本身。从这个角度来说，使用微服务后，代码修改、测试、打包以及部署的成本和风险都比单块架构系统降低很多。
按需伸缩
单块架构系统由于单进程的局限性，水平扩展时只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。 而服务架构则可以完美地解决伸缩性的扩展问题。系统可以根据需要，实施细粒度的自由扩展。
错误隔离性
微服务架构同时也能提升故障的隔离性。例如，如果某个服务的内存泄露，只会影响自己，其他服务能够继续正常地工作。与之形成对比的是，单块架构中如果有一个不合格的组件发生异常，有可能会拖垮整个系统。
团队全功能化
康威定律（Conway’s law）指出：一个组织的设计成果，其结构往往对应于这个组织中的沟通结构（organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations）。传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，团队需要具备服务设计、开发、测试到部署所需的所有技能。
4. 微服务快速开发实践
随着团队对业务的理解加深和对微服务实践的尝试，数个微服务程序已经成功构建出来。不过，问题同时也出现了：对于这些不同的微服务程序而言，虽然具体实现的代码细节不同，但其结构、开发方式、持续集成环境、测试策略、部署机制以及监控和告警等，都有着类似的实现方式。那么如何满足DRY原则并消除浪费呢？带着这个问题，经过团队的努力，Stencil诞生了。 Stencil是一个帮助快速构建Ruby微服务应用的开发框架，主要包括四部分：Stencil模板、代码生成工具，持续集成模板以及一键部署工具。
Stencil模板
Stencil模板是一个独立的Ruby代码工程库，主要包括代码模板以及一组配置文件模板。
代码模板使用Webmachine作为Web框架，RESTful和JSON构建服务之间的通信方式，RSpec作为测试框架。同时，代码模板还定义了一组Rake任务，譬如运行测试，查看测试报告，将当前的微服务生成RPM包，使用Koji给RPM包打标签等。
除此之外，该模板也提供了一组通用的URL，帮助使用者查看微服务的当前版本、配置信息以及检测该微服务程序是否健康运行等。
[
{
rel: "index",
path: "/diagnostic/"
},
{
rel: "version",
path: "/diagnostic/version"
},
{
rel: "config",
path: "/diagnostic/config"
},
{
rel: "hostname",
path: "/diagnostic/hostname"
},
{
rel: "heartbeat",
path: "/diagnostic/status/heartbeat"
},
{
rel: "nagios",
path: "/diagnostic/status/nagios"
}
]
配置文件模板主要包括NewRelic配置，Passenger配置、Nagios配置、Apache配置以及Splunk配置。通过定义这些配置文件模板，当把新的微服务程序部署到验收环境或者产品环境时，我们立刻就可以使用Nagios、NewRelic以及Splunk等第三方服务提供的功能，帮助我们有效的监控微服务，并在超过初始阈值时获得告警。