3.微服务设计如何建模服务

1.什么样的服务是好服务1.松耦合如果做到了服务之间的松耦合&＃xff0c;那么修改一个服务就不需要修改另外一个服务。使用微服务最重要的一点是&＃xff0c;能够独立修改以及部署单个服务而不需要修改系统的其他部分。什么会导致紧耦合呢&＃xff1f;一个典型的错误是&＃xff0c;使用紧耦合的方式走服务之间的集成&＃xff0c;从而使得一个服务的修改会导致其消费者的修改。一个松耦合的服务应该尽可能的少的知道与之协作的那些服务的信息。这也意味着&＃xff0c;应该限制两个服务之间不同调用形式的数量&＃xff0c;因为除了潜在的性能问题之外&＃xff0c;过度的通信可能会导致紧耦合。2.高内聚我们希望把相关的行为聚集在一起&＃xff0c;把不相关的行为放在别处。为什么呢&＃xff1f;因为如果你要改变某个行为的话&＃xff0c;最好能够只在一个地方修改&＃xff0c;然后就尽可能快的发布。如果需要在不同的地方做这些修改的话&＃xff0c;那么可能就需要同时发布多个微服务才能交付这个功能。在多个不同的地方进行修改会很慢&＃xff0c;同时部署多个服务的风险也很高&＃xff0c;这2个都是我们要避免的。所以&＃xff0c;找到问题域的边界就可以确保相关的行为能放在同一个地方&＃xff0c;并且它们会和其他边界以尽量松耦合的形式进行通信。2.限制上下文<<领域驱动设计>>&＃xff1a;认为任何一个给定的领域都包含多个限界上下文&＃xff0c;每个限界上下文的东西分成2部分&＃xff1a;一部分不需要与外部进行通信&＃xff0c;另外一部分则需要。每个上下文都有明确的接口&＃xff0c;该接口决定了它会暴露哪些模型给其他的上下文。限界的上下文&＃xff1a;一个由显式边界界定的特定职责。如果你想要从一个限界的上下文中获取信息&＃xff0c;或者向其发起请求&＃xff0c;需要使用模型和它显式边界进行通信。细胞之所以存在&＃xff0c;是因为细胞膜定义了什么在细胞内&＃xff0c;什么在细胞外&＃xff0c;并且确定了什么物质可以通过细胞膜。1.共享的隐藏模型有时候&＃xff0c;同一个名字在不同的上下文中有着完全不同的含义。2.模块和服务明白应该共享特定的模型&＃xff0c;而不应该共享内部表示这个道理之后&＃xff0c;就可以避免潜在的紧耦合风险。我们还识别出了领域内的一些边界&＃xff0c;边界内部是相关性比较高的业务功能&＃xff0c;从而得到高内聚。这些模块边界就可以成为绝佳的微服务候选。一般来讲&＃xff0c;微服务应该清晰地和限界上下文保持一致。熟练之后&＃xff0c;就可以省掉在单块系统中先使用模块的这个步骤&＃xff0c;而直接使用单独的服务。然而对于一个新的系统而言&＃xff0c;可以先使用一段时间的单块系统&＃xff0c;因为如果服务之间的边界搞错了&＃xff0c;后面修复的代价会很大。所以最好能够等待系统稳定下来之后&＃xff0c;再确定哪些东西作为一个服务划分出去。所以&＃xff0c;如果服务边界和领域的界限上下文能保持一致&＃xff0c;并且微服务可以很好的标识这些限界的上下文。3.过早的划分过早的将一个系统划分为微服务的代价非常高&＃xff0c;尤其是面对新领域的时候。很多时候&＃xff0c;将一个已有的代码库划分为微服务&＃xff0c;要比从头开始构建微服务简单的多。3.业务功能当你在思考组织内的限界上下文时&＃xff0c;不应该从共享数据的角度来考虑&＃xff0c;而应该从这些上下文能够提供的功能来考虑。先问自己 &＃39;这个上下文是做什么用的&＃39;&＃xff0c;然后再考虑 &＃39;它需要什么样的数据&＃39;。建模服务时&＃xff0c;应该将这些功能作为关键操作提供给其他写作者(其他服务).4.逐步划分上下文一开始你会识别出一些粗粒度的限界上下文&＃xff0c;而这些限界的上下文可能又包含一些嵌套的限界上下文。当考虑微服务的边界的时候&＃xff0c;首先考虑比较大的&＃xff0c;粗鲁度的那些上下文&＃xff0c;然后当发现合适的缝隙后&＃xff0c;再进一步划分出那些嵌套的上下文。有一种做法是&＃xff0c;使用这些嵌套的上下文不直接对外可见。对于外界来说&＃xff0c;它们用的还是仓库的功能&＃xff0c;但发出的请求其实被透明的映射到了2个或者更多的服务上。通常很难说哪种规则比较合理&＃xff0c;但是你应该根据组织结构来决定&＃xff0c;到底是使用嵌套的方法还是完全分离的方法。如果是不同的团队维护&＃xff0c;那么他们大概会希望都是顶层微服务。如果都是同一个团队管理&＃xff0c;那么嵌套结构会更合理。另外一个倾向嵌套方法的原因是&＃xff1a;它可以使得架构更成块从而更好的测试。5.关于业务概念的沟通修改系统的目的是为了满足业务需求。我们会修改面向客户的功能。如果把希望分解成为限界上下文来表示领域的话&＃xff0c;那么对于某个功能所要做的修改&＃xff0c;就更倾向于局限在一个单独的微服务边界之内。这样就减小了修改的范围&＃xff0c;并能够更快速的进行部署。微服务之间如何就同一个业务概念进行通信&＃xff0c;也是一件很重要的事情。基于业务领域的软件建模不应该止于限界上下文的概念。在组织内部共享的那些相同的术语和想法&＃xff0c;也应该被反映到服务的接口上。以跟组织通信相同的方式&＃xff0c;来思考微服务之间的通信形式是非常有用的。事实上&＃xff0c;通信形式在整个组织范围内都非常重要。6.技术边界

如何建模服务