站内内容投放计划,怎么做网页代码,中国室内设计网联盟,北京中国建设部网站一、设计原则之分层架构
应用分层看起来很简单#xff0c;但每个程序员都有自己的一套方法#xff0c;哪怕是初学者#xff0c;所以实施起来并非易事
最早接触的分层架构应该是最熟悉的 MVC#xff08;Model - View - Controller#xff09;架构#xff0c;其将应用分成…一、设计原则之分层架构
应用分层看起来很简单但每个程序员都有自己的一套方法哪怕是初学者所以实施起来并非易事
最早接触的分层架构应该是最熟悉的 MVCModel - View - Controller架构其将应用分成了模型、视图和控制层可以说引导了绝大多数开发者
而现在的应用包括框架中非常多架构设计都使用此模式
之后又演变出了 MVPModel - View - Prosenter和 MVVMModel - View - ViewModel
这些可以说都是随着技术的不断发展为了应对不同场景所演化出来的模型
而微服务的每个架构都可以再细分领域模型
经典的领域模型架构包括Domain、Service 和 Reposotories
核心实体Entity和值对象Value Object应该在 Domain 层定义的领域服务Domain Service在 Service 层而针对实体和值对象的存储和查询逻辑都应该在 Reposotories 层
值得注意的是不要把 Entity 的属性和行为分离到 Domain 和 Service 两层中去实现即所谓的贫血模型史诗证明这样的实现方式会造成很大的维护问题
基于这种设计工程的结构可以构造为
- MicroService-Sample/src/domaingatewaysinterfacerepositoriesservices
当然在微服务的架构中每个微服务不必严格遵守这样的规定切忌死搬硬套最重要的是理解业务
在不同的业务场合架构的设计可以适当地调整毕竟适合的架构一定要具有灵活性 分层原则
文件夹分层法
应用分层采用文件夹方式的优点是可大可小、简单易用、统一规范可以包括 5 个项目也可以包括 50 个项目以满足所有业务应用的多种不同场景
调用规约
在开发过程中需要遵循分层架构的约束禁止跨层次的调用
下层为上层服务
以用户为中心以目标为导向
上层业务逻辑层需要什么下层数据访问层就提供什么而不是下层业务逻辑层有什么就向上层业务逻辑层提供什么
实体层规约
Entity 是数据表对象不是数据访问层对象
DTO 是网络传输对象不是表现层对象
BO 是内存计算逻辑对象不是业务逻辑层对象不是只能给业务逻辑层使用
若仅限定在本层访问则导致单个应用内大量没有价值的对象转换
以用户为中心类设计实体类可以减少重复对象和无用转换
U 型访问
下行时表现层是 Input业务逻辑层是 Process数据访问层是 Output
上行时数据访问层是 Input业务逻辑层是 Process表现层是 Output 二、 设计原则之统一通信协议
接口调用如果是远程调用那么就构成了简单的分布式
最简单的远程接口实现方式是 Web Service 或 REST
当然一个合理的分布式应用不仅仅是远程接口调用这么简单还需要有负载均衡、缓存等功能
实现分布式最简单的技术是 REST 接口因为 REST 接口可以使用现存的各种服务器比如使用负载均衡服务器和缓存服务器来实现负载均衡和缓存功能
关于通信协议不同的公司有不同的选择但是建议同一个公式内部使用统一的通信协议比较典型的有 GRPC 和 BRPC
GRPC 是一个高性能、开源和通用的 RPC 框架面向移动和 HTTP/2 设计
目前提供 C、Java 和 Go 语言版本分别是 GRPC、GRPC-Java、GRPC-Go其中 C 版本支持 C、C、NodeJs、Python、Rubby、Objective-C、PHP 和 C#
GRPC 基于 HTTP/2 标准设计带来诸如双向流、流控、头部压缩、单 TCP 连接上的多重用请求特性这些特性使得其在移动设备上表现更好更省电和节省空间占用 与 GRPC 类似BRPC 源自百度目前支撑百度内部大约 75 万个在线的实例
其实基于以上的集中选择都能够完成高校的开发团队内部使用统一的标准这样更有利于模块化和统一标准
服务间的通信通过轻量级的 Web 服务使用同步的 REST API 进行通信
在实际的项目应用中一般推荐在查询是使用同步机制在增删改时使用异步的方式结合消息队列来实现数据的操作以保证最终的数据一致性 REST API 应为创建、检索、更新和删除操作使用标准 HTTP 动词而且应特别注意操作是否幂等
POST 操作可用于创建资源。POST 操作的明显特征是它不是幂等的。举例而言如果使用 POST 请求创建资源而且启动该请求多次那么每次调用后都会创建一个新的唯一资源
GET 操作必须是幂等的且不会产生意外结果。具体来讲带有查询参数的 GET 请求不应用于更改或更新信息而应使用 POST、PUT 或 PATCH
PUT 操作可用于更新资源。PUT 操作通常包含要更新的资源的完整副本使该操作具有幂等性
PATCH 操作允许对资源执行部分更新。它们不一定是幂等的具体取决于如何指定增量并应用到资源上。例如如果一个 PATCH 操作表明一个值应从 A 改为 B那么它就是幂等的。若它已经启动多次而且值已是 B则没有任何效果。对 PATCH 操作的支持仍不一致。例如JavaEE 7 中的 JAX-RS 中没有 PATCH 注解
DELETE 操作用于删除资源。删除操作是幂等的因为资源只能删除一次。但是返回代码不同因为第一次操作将成功200而后续调用不会找到资源204 参考资料《微服务架构实战》—— 张锋 一 叶 知 秋奥 妙 玄 心
