做兼职在什么网站上找,怎样建公司网站,网站推广页,做海产品的外贸网站文章目录 微服务架构是什么软件架构是什么软件架构的定义软件架构的41视图模型为什么架构如此重要 什么是架构风格分层式架构风格六边形架构风格微服务架构风格什么是服务什么是松耦合共享类库的角色 为应用程序定义微服务架构识别操作系统根据业务能力进行拆分业务能力定义了一… 文章目录 微服务架构是什么软件架构是什么软件架构的定义软件架构的41视图模型为什么架构如此重要 什么是架构风格分层式架构风格六边形架构风格微服务架构风格什么是服务什么是松耦合共享类库的角色 为应用程序定义微服务架构识别操作系统根据业务能力进行拆分业务能力定义了一个组织的工作识别业务能力从业务能力到服务 根据子域进行拆分拆分指导原则单一职责原则SRP闭包原则CCP 拆分单体服务的痛点定义服务API把系统操作分配给服务确定支持服务协作所需要的API 小结 微服务架构是什么
软件架构是什么
软件架构的定义
看一下大佬是怎么说的 计算机系统的软件架构是构建这个系统所需要的一组结构包括软件元素、它们之间的关系以及两者的属性。 --Bass等著《Documenting Software Architectures:Views and Beyond》
这个定义将软件分解为元素和元素之间的关系两个部分就像一辆汽车可以分为发动机、底盘、轮胎等元素同时各个元素之间还存在关系他们需要互相交互汽车才能正常使用。这样分解有以下两个原因
它促进了劳动和知识的分工。不同的团队可以高效系统工作。它定义了软件之间的交互方式
软件架构的41视图模型
从4个不同的视角来看一个软件的价架构 逻辑视图由开发人员创建的软件元素在面向对象的语言中这些元素就是类和包他们之间关系就是继承、关联、依赖等。实现视图由构建编译系统创建元素就是模块和可执行文件。在Java中模块就是JAR文件组件通常是WAR文件或者可执行的JAR文件。他们之间的关系就是模块之间的依赖关系以及组件和模块之间的组合关系。进程视图运行时的组件。每个元素都是一个进程进程之间的关系进程间的通信。部署视图运行在机器上的进程。进程如何映射到机器。元素是机器或虚拟机 如docker机器之间的关系代表网络。
除了这四个视图以外41中的1是指场景它负责把视图串联在一起。每个场景负责描述在一个视图中的多个架构元素如何协作以完成一个请求。例如在逻辑视图中的场景展现了类是如何协作的。同样在进程视图中的场景展现了进程是如何协作的。41视图是描述应用程序的绝佳方式。每一个视图都描述了架构的一个重要侧面场景把视图中的元素和协作串联在一起。
为什么架构如此重要
应用程序有两个层面的需求
功能性需求这些需求决定了程序可以提供哪些功能。这些功能和应用的架构没有任何关系只要能实现功能就行用哪种架构都可以。非功能性需求可以称之为质量属性需求它决定了程序运行时的质量可扩展性、可靠性。也决定了开发阶段的质量包含可维护性、可测试性、可扩展性、可部署性。为应用程序选择的架构决定了这些质量属性。
个人理解这段说的就是我们在完成老板或者产品给的一个需求的时候除了实现功能以外还要自己考虑实现的方式是不是能可扩展高可用等等。实现架构如果不合适项目随时间会变得复杂不易维护和扩展这时候还得需要治理。
什么是架构风格
像不同时代不同国家的建筑有着不同的建筑风格一样软件架构也有几种不同的风格。什么是架构风格David Garlan 和 Mary Shaw (An Introduction to Software Architecture,January 1994)这两位软件架构学科的先驱是这样定义的
因此架构风格根据结构组织模式定义了一系列此类系统。更具体地说架构风格确定可以在该风格的实例中使用的组件和连接器的词汇表以及关于如何组合它们的一组约束。详情链接https://wwwcs.cmu.edu/afs/cs/project/able/ftp/intro softarch/intro softarch.pdf
太抽象了。不深究先来看看具体的几种架构风格
分层式架构风格
表现层包含对外提供的API接口业务逻辑层包含业务逻辑数据持久层实现与数据库交互逻辑
弊端
单一表现层无法展现应用程序可能不仅由单个系统调用的事实。单一数据持久化层:它无法展现应用程序可能与多个数据库进行交互的事实。将业务逻辑层定义为依赖于数据持久化层:理论上这样的依赖性会妨碍你在没有数据库的情况下测试业务逻辑。
个人感觉说的是没错但这几个弊端貌似都影响不大呢工作中也是分层架构也是一种很常用的架构
六边形架构风格
https://alistair.cockburn.us/hexagonal-architecture/
微服务架构风格
微服务架构也是一种架构风格。它的实现视图由多个组件构成:一组可执行文件或 WAR文件。 它的组件是服务连接器是使这些服务能够协作的通信协议。每个服务都有自己的逻辑视图架构通常也是六边形架构.(感觉三层架构更多些) 微服务架构将应用程序构建为松耦合、可独立部署的一组服务。请参阅:http://microservices.iolpatterns/microserviceshtmlFTGO可能微服务架构如下
什么是服务
什么是松耦合
微服务架构的最核心特性是服务之间的松耦合性(https://enwikipediaorg/wiki/Loosecoupling)。服务之间的交互通过API完成这样做有以下几个好处
封装了服务的实现细节。允许服务在不影响客户端的情况下对实现方式做出修改。避免了外界对服务的数据库的直接访问和调用。服务自身的持久化数据就如同类的私有属性一样是不对外的。保证数据的私有属性是实现松耦合的前提之一。允许开发者修改服务的数据结构而不用提前与其他服务的开发者互相协商。这样做在运行时也实现了更好的隔离。例如一个服务的数据库加锁不会影响另外的服务。但在服务间不共享数据库的弊端特别是处理数据一致性和跨服务查询都变得更为复杂。 松耦合服务是改善开发效率、提升可维护性和可测试性的关键。小的、松耦合的服务更容易被理解、修改和测试。
共享类库的角色
开发中我们经常把一些通用的功能打包到库或模块中目的就是为了多个应用程序用到他的时候可以重用它而无需复制代码。 如果没有 Maven或npm库我们今天的开发工作都会变得更困难。那么我们可能就会想在微服务架构中使用是否能使用共享库好呢?表面上看它似乎是减少服务中代码重复的好方法。但是我们这样做的时候需要确保不会意外地在服务之间引入耦合。举个栗子 假如多个服务需要更新 order 业务对象的场景一种选择是将该功能打包为可供多个服务使用的库。这样做的优点是可以消除代码重复。缺点是如果业务需求的变更影响了 order业务对象开发者需要同时重建和重新部署所有使用了共享库的服务。这就非常麻烦了。相比之下更好的选择是把这些可能会更改的通用功能(例如order 管理)作为服务来实现而不是共享库。
所以我们应该尽量把不太可能改变的功能放入共享库中。例如在典型的应用程序中如果在每个服务中都实现一个通用的 Money类(例如用来实现币种转换等固定功能)没有任何意义它不会经常改变而且也很通用这样就可以把它放到共享类库中。
为应用程序定义微服务架构
如何定义一个微服务架构呢文章中介绍了一个三部式流世界上没有一个完美的机械化方法可以遵循这个也只是大概方法 现实中还需要具体分析I不断的迭代。三部式流程如下 1. 定义系统操作 根据功能性需求文档定义系统可以提供的操作。如FTGO中顾客需要下单那么系统就需要提供需要提供让顾客下单的操作而商家需要接单那么商家还需要提供给可以让接单的操作。 2. 定义服务 这里说的就是如何分解服务。有几种策略可供选择。一种源于业务架构学派的策略是定义与业务能力相对应的服务。另一种策略是围绕领域驱动设计的子域来分解和设计服务。但这些策略的最终结果都是围绕业务概念而非技术概念分解和设计的服务。什么是子域简单来说一个子域是的领域Domain的子部分。无论公司的规模如何每个领域都可以划分为子域通过这样做我们将公司领域的整个复杂性划分为更小的部分我们将拥有能够很好地理解业务方面的领域专家因为它是一个特定的子域。 3. 定义服务API和协作方式 定义应用程序架构的第三步是确定每个服务的API。为此你将第一步中标识的每个系统操作分配给服务。服务可以完全独立地实现操作。或者它可能需要与其他服务协作。在这种情况下你可以确定服务的协作方式这通常需要服务来支持其他操作。你还需要确定选用第3章中描述的哪种进程间通信机制来实现每个服务的API。
识别操作系统
待补充
根据业务能力进行拆分
业务能力是一个来自于业务架构建模的术语。业务能力是指一些能够为公司(或组织)产生价值的商业活动。特定业务的业务能力取决于这个业务的类型。例如保险公司业务能力通常包括承保、理赔管理账务和合规等。在线商店的业务能力包括:订单管理、库存管理和发货等等 模式:根据业务能力进行服务拆分 定义与业务能力相对应的服务。请参阅:http://microservicesio/patterns/decomposition/%20decompose-by-business-capability.html
业务能力定义了一个组织的工作
组织的业务能力通常是指这个组织的业务是做什么它们通常都是稳定的。与之相反组织采用何种方式来实现它的业务能力是随着时间不断变化的。这个准则在今天尤其明显很多新技术在被快速采用商业流程的自动化程度越来越高。例如不久之前你还通过把支票交给银行柜员的方式来兑现支票现在很多ATM 机都支持直接兑现支票而今人们甚至可以使用智能手机拍照的方式来兑现支票。正如你所见“兑现支票”这个业务能力是稳定不变的但是这个能力的实现方式正在发生戏剧性的变化。
这段作者讲的挺好业务能力是稳定的也就定义了一个组织的工作但实现业务能力方式确实随着时间不断变化的事实也确实如此。
识别业务能力
一个组织有哪些业务能力是通过对组织的目标、结构和商业流程的分析得来的。每一个业务能力都可以被认为是一个服务除非它是面向业务的而非面向技术的。业务能力规范包含多项元素比如输入和输出、服务等级协议(SLA)。例如保险承保能力的输人来自客户的应用程序这个业务能力的输出是完成核保并报价。 业务能力通常集中在特定的业务对象上。例如理赔业务对象是理赔管理功能的重点能力通常可以分解为子能力。例如理赔管理能力具有多个子能力包括理赔信息管理、理赔审核和理赔付款管理。 把FTGO的业务能力逐一列出如下所示。
供应商管理 Courier management:送餐员相关信息管理 Restaurant information management:餐馆菜单和其他信息管理例如营业地址和时间
消费者管理:消费者有关信息的管理订单获取和履行。 Order management:让消费者可以创建和管理订单 Restaurant order management:让餐馆可以管理订单的生产过程
送餐 Courier availabilitymanagement:管理送餐员的实时状态 Deliverymanagement:把订单送到用户手中。
会计记账。 consumeraccounting:管理跟消费者相关的会计记账 Restaurant accounting:管理跟餐馆相关的会计记账 Courieraccounting:管理跟送餐员相关的会计记账。 其他
这个能力层次的有趣方面是有三个餐馆相关的能力:餐馆信息管理、餐馆订单管理和餐馆会计记账。那是因为它们代表了餐馆运营的三个截然不同的方面。
从业务能力到服务
业务能力定义清楚了就可以将业务能力映射到对应的服务了。将FTGO业务能力映射到服务如下 映射理由如下
供应商管理的子能力映射到两种服务是因为餐馆和送餐员是非常不同类型多的供应商。我将订单获取和履行能力映射到三个服务每个服务负责流程的不同阶段。我将送餐员可用性管理(Courier availability management)和交付管理( Delivery management)能力结合起来并将它们映射到单个服务因为它们交织在一起。我将三个不同的会计记账能力映射到同一个服务因为这几个不同类型的会计记账看起来很相似。
围绕能力组织服务的一个关键好处是因为它们是稳定的所以最终的架构也将相对稳架构的各个组件可能会随着业务的具体实现方式的变化而发展但架构仍保持不变
根据子域进行拆分
待补充
拆分指导原则
单一职责原则SRP
改变一个类应该只有一个理由。-Robert C.Martin
如果一个类承载了多个职责并且互相之间的修改是独立的那么这个类就会变得非常不稳定。所以定义的每一个类都应该只有一个职责因此也就只有一个理由对它进行修改。我们在设计微服务架构时也应该遵循SRP 原则设计小的、内聚的、仅仅含有单一职责的服务。这会缩小服务的大小并提升它的稳定性。新的FTGO架构是应用SRP的一个例子为客户获取餐食的每一个方面(订单获取、订单准备、送餐等) 都由一个单一的服务承载。其实这个原则在实现类的每个方法时每个类时也都会用到。
闭包原则CCP
在包中包含的所有类应该是对同类的变化的一个集合也就是说如果对包做出修改需要调整的类应该都在这个包之内。-Robert C.Martin 闭包原则就是如果一个类的修改另一个类也必须修改那么就要把他们两个放到一个包里这里做目的是当业务规则发生变化时开发者只需要对一个包做出修改可以极大改成程序的可维护性。同样我们可以把它应用到拆分服务中如果一个服务变化会影响到另一个服务我们就把这两个服务放在一个组件中这样做可以控制服务数量防止拆分出的服务数量过多变更和部署也更容易。理想情况下一个变更只会影响一个团队和一个服务。CCP有效解决分布式单体的反模式法宝。
拆分单体服务的痛点
网络延迟 分布式系统网络延迟是分布式系统中一直存在的问题。、服务的特定分解会导致两个服务之间的大量往返调用。有时我们可以通过实施批处理 API在一次往返中获取多个对象从而将延迟减少到可接受的数量。但在其他情况下解决方案是把多个相关的服务组合在一起用编程语言的函数调用替换昂贵的进程间通信。就是把多个相关的服务写成一个本地调用肯定要比进程间通信要快。同步进程间通信导致可用性降低 A服务要调用B服务如果二者是同步调用B服务不可用了或者是挂了那么A服务部分功能可能就不能用了。但是在第3章中学习异步消息之后你就会发现其实有更好的办法来消除这类同步调用产生的紧耦合并提升可用性。在服务之间维持数据一致性 对于一些系统操作可能需要同时更新多个模块的数据。如电商系统中用户下单操作需要调用订单管理模块的方法新增一条订单到数据库同时需要调用库存模块的方法锁定一个商品库存更新库存数量。还需要调用支付模块的方法新增一条支付记录状态为待支付。如果用户在规定时间内支付了需要更新库存-1订单状态改为已支付等。如果用户未在规定时间内支付锁定的库存需要释放订单状态改为已取消支付状态改为支付超时等 。这个系统操作所涉及到的订单、支付、库存等操作需要保证原子性。要么全部成功要么全部失败。假如支付成功了库存扣减失败了那是不行的。如果是在单体系统中可以操作属于一个本地事务我们可以通过数据库的事务来保证。但是在微服务架构中订单、库存、支付分属于三个服务每个服务有有对应的数据库要保证一致性就需要分布式事务。传统的解决方案是使用基于两阶段提交(two phase commit)的分布式事务管理机制。 书中作者没有对两阶段提交详细介绍想了解可以参考这篇文章链接 但是作者提到了使用一种非常不同的方法来处理事务管理这就是Saga。Saga 是一系列使用消息协作的本地事务。Saga 比传统的ACID 事更复杂但它们在许多情况下都能工作得很好。Saga 的一个限制是它们最终是一致的。如果你需要以原子方式更新某些数据那么它必须位于单个服务中这可能是分解的障碍。后边章节会详细讲。获取一致的数据视图 分解的另一个障碍是无法跨多个数据库获得真正一致的数据视图。在单体应用程序中,ACID 事务的属性保证查询将返回数据库的一致视图。相反在微服务架构中即使每个服务的数据库是一致的你也无法获得全局一致的数据视图。如果你需要一些数据的一致视图那么它必须驻留在单个服务中这也是服务分解所面临的问题。幸运的是在实践中这很少带来真正的问题。上帝类阻碍了拆分
定义服务API
把系统操作分配给服务
第一步是确定哪个服务是请求的初始入口点。许多系统操作可以清晰地映射到服务如创建订单很明显是订单服务但有时映射会不太明显。例如考虑使用noteUpdatedLocation()操作来更新送餐员的位置。一方面因为它与送餐员有关所以应该将此操作分配给 Courier Service。另一方面它是需要送餐地点的 Delivery Service。在这种情况下将操作分配给需要操作所提供信息的服务是更好的选择说的很绕啊。在其他情况下将操作分配给具有处理它所需信息的服务可能是有意义的。如处理findAvailableRestaurants()这个操作需要从RestaurantService服务查信息所以就把这个操作分配到这个服务。
确定支持服务协作所需要的API
把操作分配给服务后下一步是确定在处理每一个系统操作时服务之间如何交互。 某些系统操作完全由单个服务处理。例如在FTGO应用程序中ConsumerService完全独立地处理 createconsumer()操作。但是某些系统操作跨越多个服务处理这些请求之一所需的数据可能分散在多个服务周围。例如createOrder()操作orderService必须调用以下服务以验证其前置条件并使后置条件成立: Consumer Service:验证消费者是否可以下订单并获取其付款信息。 Restaurant Service:验证订单行项目验证送货地址和时间是否在餐厅的服区域内验证订单最低要求并获得订单行项目的价格 Kitchen Service:创建Ticket(后厨工单) AccountingService:授权消费者的信用卡 为了完整定义服务API你需要分析每个系统操作并确定所需的协作。其实到这一步就是具体问题具体分析了。
小结
1.架构决定了软件的各种非功能性因素比如可维护性、可测试性、可部署性和可扩展性它们会直接影响开发速度。这也是软件架构重要的原因 2. 微服务架构是一种架构风格它给应用程序带来了更高的可维护性、可测试性、可部署性和可扩展性。 3. 微服务中的服务是根据业务需求进行组织的按照业务能力或者子域而不是技术上的考量。 4. 有两种分解模式 按业务能力分解其起源于业务架构 基于领域驱动设计的概念通过子域进行分解。可以通过应用DDD并为每个服务定义单独的领域模型 5. 可以通过应用DDD并为每个服务定义单独的领域模型来消除上帝类正是上帝类引起了阻碍分解的交织依赖项。
