spring 微服务架构设计

微服务探秘

微服务的变化，是继面向服务的架构SOA之后，微服务与DevOps以及云计算相辅相成的流行的设计模式

要看交付能力表，微服务的敏捷性高，交付速度更快，扩展能力更强。

例如：航空系统公司不会透入资源将其核心主机订票系统重建为单体巨兽。金融系统不会重建将核心银行业务系统，零售系统和其他行业系统也不会重建重量级的供应链管理系统，传统的ERP行业，各行业的焦点已经从构建大型系统转移到尽可能敏捷的方式构建适应特定业务需求并快速取胜的各个类单点解决方案。

微服务的催化剂，NoSQL数据库彻底改名了2阶段提交的开发分布式应用

Html5和CSS3的出现以及移动应用的发展，重新定义了UI，由于响应式和自适应设计方面突出的表现，Angualar，Ember React Backbone等都是javascript框架流行开了。云计算Pivotal CF、AWS、Sales Force、IBM Bluemix、RedHatOpenShift等平台Paas

厂商促使我们重新思考重构中介件方式。Docker引发了容器化革命极大的影响基础设施建设 mesosphere dcos等容器编排工大量简化基础设施管理。

不同的架构方法和风格，大型主机架构，C/S架构，N层架构，面向服务架构，这些架构的特点是单体架构系统，而微服务是在上演化而来的。

 

什么是微服务？

微服务是一种架构分格。

微服务并不是发明出来的。而是将功能单体应用分割成更小的原子应用。每个原子应用只实现单一的动能。这种架构称为微服务架构

图1 传统设计模式

 上图表现传统的设计模式，模块A、模块B、模块C分别代表3个业务功能，展现层也包含3个模块的业务逻辑组件。而数据库包含3个模块的所有数据，大多数情况下，不同层的在物理的隔离的，而不同的模块是硬编码。

微服务的结构

图 2 微服务设计模式

 图2所示，微服务架构中的边界被反转了。每个垂直的条状结构代表着一个微服务，微服务和业务功能相对应或者是一致，不会影响到其他微服务上。

微服务间不存在标准的通信或者传输机制，微服务之间的通信使用广泛的Http或者事后rest，或者基于消息机制的协议，比如JMS或者是AMQP，在某种情况下，优化消息通信协议，比如Thrift ZeroMQ，Protocal buffers或者是Avro

Devops是重组IT资源的方式，可以高效运维。

微服务的设计原则

每个服务承担单一责任，SOLID设计模式中的定义的一个重要原则。每个单元只应承担一项责任。

例如：一个电商应用，客户，产品，订单是不同的功能模块。

分别出单一责任的模块如客户，产品，订单

微服务是自治

微服务是自包含且可独立部署的自治服务，负责业务功能和执行。微服务会捆绑所有依赖，包括第三方库依赖，执行环境依赖（比如Web服务器和容器）和抽象物理的虚拟机依赖。

微服务和SOA的主要区别是服务的自治服务程度

大多数的SOA的实现提供了服务级别的抽象，但微服务进一步抽象的实现和运行环境。

微服务的特性

服务是一等。微服务抽象所有的实现细节，对外通过API暴露服务端点，微服务内部的实现逻辑，技术架构，完全隐藏在服务的API之后。

微服务架构中的特性：

服务合约：微服务领域中的服务合约可用JSON和Rest广泛用于服务之间的通讯。

松耦合：微服务的各个独立且松耦合的。

服务抽象：

服务复用：

无状态化：

服务可发现性：微服务是可发现的

服务互操作性：由于微服务使用标准的协议和信息交换格式，它们是可以互操作。

微服务通常用消息和Http等传输机制，在微服务领域，REST/JSON是开发可互操作进一步优化通讯的最流行的方式，会用到其他协议。

微服务是轻量级的：

微服务的混合架构

微服务是自治的，它将所有细节都抽象出来并且隐藏到服务的API之后，便于对微服务设计做不同的技术架构，微服务的实现过程包含如下共性：

• 不同的服务可采用同一项技术的不同版本。微服务可以在java1.7上开发，而另外一个微服务在java1.8上开发。
• 不同的服务可以采用的不同的语言进行开发，微服务可以用java开发，也可以用Scala进行开发。
• 可采用不同的存储架构，微服务用Redis进行缓存，而另外一个微服务用Mysql进行持久性数据存储。

微服务环境的自动化

从开发环境到生产环境，大多数微服务实现最大程度的自动化

由于微服务将单体应用打散成为一系列小型服务，大企业中可能会出现微服务激增的现象。如果不采用自动化，大量的微服务将难以管理。微服务叫小资源开销也又有利于将微服务从开发到部署整个生命周期自动化。

微服务实现了端到端的自动化，自动化构建，自动化测试，自动化部署，弹性伸缩。