微服务Architecture（MicroServices）
微服务架构简单的定义
采用一组Service的方式来构建一个应用，服务独立部署在不同的进程（Container）中，不同Service通过一些轻量级交互机制来通信，例如：RPC、API、HTTP等；Service可独立扩展伸缩，每个Service定义了明确的边界，不同的Service甚至可以采用不同的编程语言来实现，由独立的团队来维护。
例如认证服务：用户登录和用户注册可以拆分为两个微服务。
微服务Architecture特征
传统组件是和应用一起运行在进程中，组件的局部变化意味着整个应用的重新部署。通过Service来实现组件，意味着将应用拆散为一系列的Service运行在不同的进程中，那么单一Service的局部变化只需重新部署对应的Service进程。另外将Service作为组件可以更明确的定义出组件的边界，因为Service之间的调用是跨进程的。
微服务架构应用
采用微服务架构面临的第一个问题就是如何将一个单一应用拆分为多个服务。 有一个一般的原则是，单一服务提供的功能是可以独立被替换和升级的。 也就是说如果有 A 和 B 两个功能，如果 A 功能发生变化时同时 B 功能也需要变化，那么 A 和 B 这两个功能应该被划在一个服务中。
微服务架构应用的成功经验近年已越来越多，例如国外的 Amazon，Netflix，国内如阿里都采用微服务架构取得了很多正面的成功案例。 但通过上文所述微服务架构特征看出，其实微服务架构模式有利有弊，需要根据实际的业务、团队、环境进行仔细权衡利弊。 其中的服务拆分带来的额外开发、测试、运维、监控的复杂度，在现有的环境、团队下是否能够很好的支持。