《微服务架构实战》读书笔记二----微服务设计原则

《微服务架构实战》读书笔记二----微服务设计原则

设计原则之分层架构

同一公司使用统一的分层，以减少学习开发维护成本，类似MVC MVP MVVM这种分层模式，但是在微服务中不比严格遵守这种规定，切记死板硬套，最重要是理解业务，在不同的业务场合，架构可以适当调整

• 文件分层法

  应用分层采用文件夹方式的优点是可大可小的，简单易用，统一规范，可以包括5个项目，也可以包括50个项目，以满足所有业务的不同场景

• 调用规约

  开发中遵守分层架构的约束，禁止跨层调用

• 下层为上层服务

  以用户为中心，以目标为导向，上层（service）需要啥，下层（dao）就提供啥

• 实体层规约

  entity是数据表对象，不是数据访问对象，DTO是网络传输对象，不是表现层对象，BO是内存计算逻辑对象，不是业务逻辑层对象，不是只能给业务逻辑层使用，如果仅仅限定在本层访问，则导致单个应用内大量没有价值的对象转换，以用户为中心设计实体类，可以减少无价值重复对象和无用转换

• U型访问

  下行时候表现层是input，业务逻辑层是process，数据访问层是output

  上行时候数据访问层是input，业务逻辑层是process，表现层是output

设计原则之统一通信原则

通信协议一般采用Rest，WebService，或者RPC

当然不仅仅是解决远程调用就行，还得解决负载均衡，缓存等等功能，最简单的实现是Rest接口，因为其可以使用现存的各种服务器。实现负载均衡和缓存功能

服务间通信通过轻量级Web服务，使用同步Rest API进行通信，在实际的项目中，存在一般推荐在查询使用同步机制，增删改使用异步，结合消息队列实现数据操作，以保证最终的数据一致性

使用Rest API 应该注重是否等幂操作

设计原则之单一职责

这个很简单，单个服务的职责必须单一，如果职责不单一则不利于扩展和复用，这样维护成本也低

单一职责的优点

• 类复杂性降低，实现什么职责都有清晰明确的定义
• 可读性提高，复杂性降低
• 可维护性提高，可读性提高

实施单一职责的目的在于

• 以类来隔离需求功能点，一个点需求改变，不会影响其他
• 一个业务设计到底多小，应该由专家共同参与讨论
• 粒度小，灵活，复用性强，方便更高级别抽象

每个微服务单独运行，能够实现松耦合，独立部署

设计原则之服务拆分

服务拆分不应该过于追求细粒度，要考虑适中，不能过大或过小，在业务域，团队，技术水平上追求平衡

拆分可以分为三个方向

x：水平复制，类似把整个系统负责一遍，做个集群，就是单机架构做集群后，再负载均衡这种

y：功能分解，不同职能的模块分开成不同服务，例如，订单服务，商品服务等等

z：对数据库扩展，即分库分表

举个例子；

拆分应用

x：从单体系统或服务，水平克隆出许多系统，通过负载均衡平均分配请求

y：面向服务分割，例如，电商网站，登录，搜索，下单等等服务进行y轴拆分

z：面向查找分割，将不同产品的SKU分到不同服务

要做好微服务的分层，梳理核心应用，公共业务，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心。

对于服务拆分，使用迭代的方法，不能一次性完成所有微服务拆分

设计原则之前后端分离

前后端分离是一种架构模式，并不只是开发模式，在开发阶段，前后端约定好数据交互接口，实现并行开发和测试，在运行阶段前后端分离模式需要对web应用进行分离部署，前后端采用http或者其他协议交互请求

前后端使用json数据交互，两个开发团队使用api作为契约进行交互。

核心在于，后台提供数据，前端负责显示，实现定义好交互的数据类型格式，通过json传输数据

设计原则之版本控制

在团队的内部，尤其是API优先设计的微服务中，接口的版本管理显得尤其重要，微服务的一个主要优势是允许服务独立演变，考虑微服务会调用其他服务，这种独立性要引起高度注意，不能在API中破坏性更改

版本控制的方法

• 将版本放入url中
• 使用自定义请求标头
• 将版本放在HTTP Accept标头中，并依靠内容协商

设计原则之围绕业务构建

各个系统之间合理使用消息队列，解决系统或模块之间的异步通信，每个子系统之间的技术栈选择，不用那么死板，应该针对业务选择合适的技术栈

设计原则之并发流量控制

大流量的指标一般是TPS(每秒事务量),QPS（每秒请求数），其实这没一个绝对标准，一般根据机器的配置情况而定，如果当前配置不能应对请求量，那么就是大流量

应对方案

• 缓存
• 降级，如果不是核心链路，就把这个业务降级，保证主干畅通
• 限流，一定时间范围内，只能允许一批流量进入