1. 什么是微服务？
微服务是指开发一个单个、小型、具备有业务功能的服务。其特点如下：
2. 传统应用架构与微服务架构的区别
单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个BUG，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个BUG 将会影响到整个应用的可靠性。
3. 康威定律：设计系统的组织，最终产生的设计会反映出组织内部和组织之间的沟通结构。
“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
—— Melvin Conway 1960’s
传统的MVC架构，会导致任何一个需求改变都必须要跨团队交流。
微服务这种极度松耦合的架构需要极度松耦合的组织团队。
按业务而不是按功能划分服务，每个服务可以使用不同的技术堆栈，每个服务是跨功能的，团队成员是拥有全部的技能。
成功案例：www.comparethemarket.com
跨功能团队负责每个产品的建立，每个产品被分离成许多独立的服务，之间通过消息总线通讯。
4. 微服务与SOA的区别
从表面上看，微服务架构模式有点像SOA，它们都是由多个服务构成。
从业务角度看，微服务是具备有业务功能的服务，而SOA中Web服务可能是个非业务功能的原子服务。
从技术角度看，微服务架构模式是一个不包含Web服务（WS-）和 ESB服务的SOA。微服务应用采用简单轻量级协议，比如REST，而不是WS-，在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也 拒绝使用canonical schema等SOA概念。
延伸阅读：Canonical Schema Pattern
The Canonical Schema pattern ensures that services are built with contracts capable of sharing business documents based on standardized data models (schemas).
The application potential of Canonical Schema can become one of the fundamental influential factors that determine the scope and complexion of a service inventory architecture.
参考文献：
1. http://www.jdon.com/46204
2. http://www.jdon.com/soa/microservice-architecture.html
3. http://www.bettersoftwaredesign.org/Design-Patterns/SOA-Service-Patterns/Foundational-Inventory-Patterns/Canonical-Schema-Pattern
微服务是指开发一个单个、小型、具备有业务功能的服务。其特点如下：
- 每个服务运行在自己的进程中，通过轻量的通讯机制（基于HTTP/REST API）联系。
其中，使用 REST API 更好些，因为 REST本身就是 Web，而不是基于 Web：“Be of the web, not behind the web”。 - 每个服务可以使用不同的编程语言编写。
- 每个服务提供一个模块边界，服务上下文。
- 每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。
- 每个服务能够通过自动化方式独立地部署在单个或多个服务器上。
- 每个服务能够通过自动化方式弹性扩展伸缩。
- 每个服务能够独立更换、独立升级，而不影响其它服务。
- 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一的数据库。
2. 传统应用架构与微服务架构的区别
单体式应用的需求的一个小改变会导致整个系统重新构建重新部署，难以让变化只影响在一个模块内，进行扩展伸缩时也只能整个系统扩展，而不能针对其一部分扩展其资源能力。
单体式应用在不同模块发生资源冲突时，扩展将会非常困难。比如，一个模块对CPU敏感，另外一个内存数据库模块对内存敏感。然而，由于这些模块部署在一起，因此不得不在硬件选择上做一个妥协。
单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个BUG，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个BUG 将会影响到整个应用的可靠性。
3. 康威定律：设计系统的组织，最终产生的设计会反映出组织内部和组织之间的沟通结构。
“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”
—— Melvin Conway 1960’s
传统的MVC架构，会导致任何一个需求改变都必须要跨团队交流。
微服务这种极度松耦合的架构需要极度松耦合的组织团队。
按业务而不是按功能划分服务，每个服务可以使用不同的技术堆栈，每个服务是跨功能的，团队成员是拥有全部的技能。
跨功能团队负责每个产品的建立，每个产品被分离成许多独立的服务，之间通过消息总线通讯。
4. 微服务与SOA的区别
从表面上看，微服务架构模式有点像SOA，它们都是由多个服务构成。
从业务角度看，微服务是具备有业务功能的服务，而SOA中Web服务可能是个非业务功能的原子服务。
从技术角度看，微服务架构模式是一个不包含Web服务（WS-）和 ESB服务的SOA。微服务应用采用简单轻量级协议，比如REST，而不是WS-，在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也 拒绝使用canonical schema等SOA概念。
延伸阅读：Canonical Schema Pattern
The Canonical Schema pattern ensures that services are built with contracts capable of sharing business documents based on standardized data models (schemas).
The application potential of Canonical Schema can become one of the fundamental influential factors that determine the scope and complexion of a service inventory architecture.
参考文献：
1. http://www.jdon.com/46204
2. http://www.jdon.com/soa/microservice-architecture.html
3. http://www.bettersoftwaredesign.org/Design-Patterns/SOA-Service-Patterns/Foundational-Inventory-Patterns/Canonical-Schema-Pattern
没有评论:
发表评论