维基百科将弹性定义为系统处理变化的能力。我对弹性的理解是在问题被解决后系统从异常状态或者压力期中优雅的恢复，同时又不会影响系统性能的能力。
这虽然看上去很简单，但是在构建面向微服务软件的时候，问题源会由于系统的分布式特性而被放大，有时很难防止所有的异常情况。
弹性是从错误中优雅回复的能力。但是同样也为系统带来了新的复杂度：如果一个微服务出现了问题，我们能否防止系统的常规故障？理想情况下，我们应该以这样一种方式来构建服务：仅对服务响应进行降级而非让系统出现常规故障，即使这样做也并不容易。
可伸缩性如今各大公司的一个通病是系统存在可伸缩性的问题。通常，这些问题并不涉及应用的每一层次或所有子系统。往往只有个别子系统或服务会明显鳗鱼其余部分，一旦没有处理好容量问题就会导致整个应用发生故障。
下图描述了如何对微服务进行扩展（扩展成两个邮件服务）的，同时又不牵扯系统的其余部分：
软件世界每几个月就出更新系统。新语言进入业界成为某类系统事实标准的节奏片刻位停。
Golang：因其结合了强大的性能与优雅简洁的语法而成为当前一种趋势，任何只要拥有一门编程语言经验的人都可以在几天学会它。
Java：自从Sping Boot 发布以后，他成为在编写敏捷服务方面相当有吸引力的技术栈。
DJango：是一款强大且可用于编写微服务的Python的框架，与Ruby on Raile 非常相似。
Node.js：利用了著名的JavaScript 的优势，创建了一个新的服务端技术栈，从而改变了工程师们编写新软件的方式。
那么，将这些语言的技术栈结合起来会有什么问题吗？平心而论，这是一个优势：我们可以选择合适的工具来做相对应的工作。只要待集成的技术是标准化的，面向微服务的架构便可以帮你实现这一点。
下图展示了微服务是如何隐藏数据的存取逻辑的，两个服务在存取数据方面共用同一个通信点，从而能很好地互相解耦：
Node.js 并不是一门适合执行并行任务的语言。针对那些处于压力之下的微服务来说，我们可以选择一门更适合的语言来进行开发，比如 Erlang，从而可以以一种更加优雅的方式来管理并发。
可替换性可替换性是指替换系统中某个组件而不影响系统行为的一种能力。
当我们在讨论软件的时候，可替换性往往是与低耦合密不可分的。在编写微服务的时候不能讲内部逻辑暴露给调用服务，服务实现对客户端来说是透明的，客户端只需要了解的只有接口。
所有服务应该都是独立的，他们通过接口进行交互。除了协定确认接口这一环节之外，不同的工程师团队可以在无需交流的情况下完成对服务的开发。
易于部署微服务应当易于部署，原因如下：
少量的业务逻辑，导致更易于部署。
微服务是自治的工作单元，所以升级一个服务对于复杂的系统来说是一个局部可控的问题。无需重新部署整个系统。
微服务架构中的基础设施和配置都应该尽可能的自动化（如 Docker 来部署微服务）。
SOA 与微服务的比较面向微服务架构（SOA）与微服务架构非常想象的。那么他们之间的区别到底是什么呢？
微服务是细粒度的 SOA 组件。换句话说，某个单个SOA组件可以拆成多个微服务，而这些微服务通过分工协作，可以提供与原SOA组件相同级别的功能，如下图：