微服务的架构

微服务架构

标题微服务架构概念

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

传统开发模式和微服务的区别

传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（单体式开发）。
所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。
优点：

①开发简单，集中式管理
②基本不会重复开发
③功能都在本地，没有分布式的管理和调用消耗
缺点：
1、效率低：开发都在同一个项目改代码，相互等待，冲突不断
2、维护难：代码功功能耦合在一起，新人不知道何从下手
3、不灵活：构建时间长，任何小修改都要重构整个项目，耗时
4、稳定性差：一个微小的问题，都可能导致整个应用挂掉
5、扩展性不够：无法满足高并发下的业务需求
常见的系统架构遵循的三个标准和业务驱动力：
1、提高敏捷性：及时响应业务需求，促进企业发展
2、提升用户体验：提升用户体验，减少用户流失
3、降低成本：降低增加产品、客户或业务方案的成本

基于微服务架构的设计：
目的：有效的拆分应用，实现敏捷开发和部署

微服务的具体特征

官方的定义：
1、一些列的独立的服务共同组成系统
2、单独部署，跑在自己的进程中
3、每个服务为独立的业务开发
4、分布式管理
5、非常强调隔离性
大概的标准：
1、分布式服务组成的系统
2、按照业务，而不是技术来划分组织
3、做有生命的产品而不是项目
4、强服务个体和弱通信（ Smart endpoints and dumb pipes ）
5、自动化运维（ DevOps ）
6、高度容错性
7、快速演化和迭代

怎么具体实践微服务

要实际的应用微服务，需要解决一下四点问题：
1、客户端如何访问这些服务
2、每个服务之间如何通信
3、如此多的服务，如何实现？
4、服务挂了，如何解决？（备份方案，应急处理机制）

常见的微服务架构设计模式：

1、聚合器微服务设计模式

这是一种最常见也最简单的设计模式：

聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步
发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。

2、链式微服务设计模式
这种模式在接收到请求后会产生一个经过合并的响应，如下图所示：

在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。
因此，服务调用链不宜过长，以免客户端长时间等待。

4、分支微服务设计模式
这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示：