三、微服务架构中的每一个微服务都是独立部署的。在这种无需协调部署其他服务来部署服务，开发人员可以更快地部署。 前端设计团队同样可以利用这个快速部署。这种架构模型可以方便地完成部署。

四、每个服务中都独立扩张。不同规模的微服务的需求都可以得到相应的满足，包括硬件资源，可以节约成本。

2.1.2 复杂性总结

一、运维开销及成本增加：整体应用或许只需部署到一小片应用服务区集群即可，而微服务架构需要变成构建、测试、部署、运行等数十个独立的服务，而且可能需要支持很多种语言以及环境。如果一个整体式系统由20个微服务组成，这可能使其需要40~60个进程。

二、必须有坚实的DevOps开发运维一体化技能：开发人员要对维与投产环境熟悉，开发人员也需要掌握像NoSQL等的数据存储技术，因为如果有较强DevOps能力的人员很少，会使招聘人才面临巨大的挑战。

三、隐式接口及接口匹配问题：将系统分成多个协作组件后就会产生新接口，这导致了简单的交叉变化需要改变更多的组件。一般情况下，一个新品发布可能不得不发布大量的服务，同时由于集成点的增加，微服务架构将会有更高的发布风险。

四、代码重复：某些底层功能需要被多个服务所用，通过向不同的服务添加一些代码，可以避免将“同步耦合引入到系统中”，这就导致了代码的重复。

五、分布式系统的复杂性：微服务是一种分布式系统，它引入了一些比较复杂的和其他的问题，这就要求开发人员要考虑这些分布式系统问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等。

六、异步机制：微服务通常使用异步编程、消息与并行机制，但是如果应用存在跨微服务的事务性处理问题，其实现机制将变得更复杂了。

七、可测性的挑战：在动态的环境下，服务间的交互会产生微妙的行为。一般情况下，经典的微服务不是很重视测试，它是通过监控来发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于那些在意风险规避监管或投产环境错误会产生显著影响的场景下，需要特别注意。文献综述

2.1.3 通用特性

一、通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立升级或者替换的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。

二、围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizzateam”- 不超过12人）。

三、产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。

四、智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。 基于SpringBoot的分布式电商系统架构设计(4):http://www.youerw.com/jisuanji/lunwen_77509.html