微服务架构的关键思想是功能分解。这意味着您无需开发单个大型应用程序,就可以将您的应用程序结构分解为一组逻辑服务。
应用程序的体系结构很重要,因为它决定了服务的质量
传统目标:可伸缩性,可靠性和安全性。
其他现代目标:快速,安全地提供服务。可维护性,可测试性和可部署性。
应用程序的体系结构是将其分解为组件以及这些组件之间的关系。
分解很重要,因为它有助于团队之间的工作和知识分配,并提供应用程序整体工作的清晰度。
软件架构的4 + 1视图模型
它定义了软件体系结构的四个视图
逻辑视图
由开发人员创建
组件:类和包
关系:他们之间的关系
开发视图 /实施意见
组件:模块(JAR)和可部署/可执行(WAR)
关系:依赖关系
进程视图
组成部分:进程
关系:IPC
物理视图
组件:机器和流程(节点)
关系:网络
4 + 1视图模型中的+1代表动画视图,并描述特定视图中的各个组件如何协同工作以处理请求。
分层架构
分层体系结构将软件组件分层组织。层可以依赖于其下面的任何层。
流行的三层架构是分层架构
分层架构的缺点
依赖性没有很好地表示。
并不表示架构可以具有多个表示层。
并不代表该体系结构可以具有多个数据存储的事实。
应用程序层与数据层紧密耦合,因此在没有数据库的情况下很难测试应用程序逻辑。
基于建筑风格的整体
整体架构可以定义为一种架构样式,该架构样式将实现 视图表示为单个组件:单个可执行文件或可部署文件。
基于架构风格的微服务
架构风格的微服务架构表示一个具有一组多个组件的实现视图:可执行文件和Wars。
组件是服务,关系是通过通信协议进行的。尽管通常实现六边形体系结构,但是各个服务可以自由选择其体系结构。
微服务架构服务的关键约束应该松散耦合。
服务是实现某些有用功能的独立,可独立部署的组件。
服务通常提供两类动作
命令:执行操作并更新数据。
查询:获取数据
服务还会发布事件。
任何两个服务将仅通过API进行通信。API隐藏了服务的内部实现。两个服务不共享同一数据库以提供运行时隔离,因此一个服务无法持有将阻止另一服务的锁。
定义应用程序的微服务架构
步骤如下:
识别系统操作。
身份服务
为每个服务及其之间的交互定义API
将系统视为黑匣子。现在确定所有系统操作。
系统操作是应用程序必须处理的请求的抽象。它可以是命令,也可以是查询。
它涉及以下操作:
收集系统的需求。
确定通常从需求中的名词派生的域模型。
确定通常从需求中的动词派生的系统操作。
从UI和UX的角度看,将在系统上执行哪些操作。
有两种方法可以识别系统中的服务:
按业务能力分解
按域驱动器设计分解
单一责任原则
一个类只有一个改变的理由。(罗伯特·马丁(Robert C.Martin))
开放关闭原则
包中的类应针对相同的更改一起封闭。影响软件包的更改会影响该软件包中的所有类。(罗伯·马丁(Rober C.Martin))
网络延迟(高往返)
由于同步通信,降低了应用程序的可用性。
维护各服务之间的数据一致性
获取数据库的一致视图。
上帝类(在所有服务中都使用的班)
服务API有两类
暴露给外部客户端。
用于内部服务协作。
来源:
https://www.toutiao.com/i6951592069697749541/
“IT大咖说”欢迎广大技术人员投稿,投稿邮箱:aliang@itdks.com
IT大咖说 | 关于版权
由“IT大咖说(ID:itdakashuo)”原创的文章,转载时请注明作者、出处及微信公众号。投稿、约稿、转载请加微信:ITDKS10(备注:投稿),茉莉小姐姐会及时与您联系!
感谢您对IT大咖说的热心支持!
相关推荐
推荐文章