qj4865的博客

浅薄的了解ddd中的repository层，就是起到一个聚合的作用。他介于domain和dao层之间，相当于一个聚合dao数据的作用。比如说我一个查询需要先查cache，命中不到再去找dao，那我这个逻辑就可以放在repo层；又比如说我一个domain层需要一组数据，这个数据是从多个表拿的，那么我就也可以吧多个dao查出来的数据，在repo层聚合。...

三大编程范式包括，结构化编程，面向对象编程，函数式编程。结构化编程范式结构化编程是指将复杂程序递归拆分成一系列更小的，可证明的单元（函数），之后通过编写测试来试图证明这些函数是错误的。如果无法证伪这些函数，就可以认为这些函数足够正确，进而推导整个程序是正确的。（注意，这里是用科学论证法进行验证，只要函数无法证伪，就能认为其足够正确；而数学论证则要求证明函数的正确性）由于需要递归的将程序拆分成更小的，可证明的单元，而使用goto语句会导致某个模块无法递归拆分，进而违背了结构化编程范式。所以，在结构化编程

适应度函数定义如下：架构的适应度函数为某些架构特征提供了客观的完整性评估。适应度函数，本质上就是一组评估函数，用以评估架构在不同维度上的表现（性能、可靠性、安全性、伸缩性、代码规范等），并从全局角度进行平衡，从而实现增量和引导式演进。适应度函数不单指特定的一种方法（如，单体测试），而是所有能够评估架构性能的方法。适应度函数可以是单体测试、功能性测试、监控工具等。但是不是所有方法都是适应度函数，只有该方法能够评估架构性能的时候，才是适应度函数（用于验证业务的单体测试就不是适应性函数）。架构师通过适应度

什么是事件溯源传统的数据对象持久化主要是将数据对象映射到数据库的表中。其中列代表了对象的属性，而行代表了一个对象（例如mysql中的行与列的关系）。传统的数据对象持久化只会保存当前对象状态，而不会保存变更之前的状态。事件溯源和传统的数据对象持久化不同的是，其主要操作对象是事件。聚合对象通过一系列事件存储在数据库中，每个事件代表聚合对象的状态改变，通过加载事件和重放事件来获取当前或者某个时间内的对象状态。事件溯源的具体操作在传统的数据持久化的操作中，直接对数据库的数据对象进行增删改查。在事件溯源

微服务运行在容器内；容器依靠K8S进行编排、服务发现、负载均衡等；Istio和K8S进行融合，在利用K8S的一些功能的基础上（服务注册），对K8S进行功能的扩展，追加了一些服务治理功能（熔断、限流、动态路由、调用链追踪）。微服务与容器为了微服务的快速部署和迭代，如今的微服务架构中，通常将微服务部署在容器内。使用容器的好处K8SK8S是一个基于容器技术的分布式架构方案。利用K8S，我们可以很好的对容器进行管理。其架构如下：K8S的最基础单位是Pod，一个Pod下可以支持许多容器，Pod中的容器.

单体架构下，大多数采用的事务的ACID原则来保证事务，但是在微服务架构下，由于要保证低耦合等的要求，采用ACD Saga的模式来保证事务。（虽然也可以使用分布式事务，即"两阶段提交"，但是这会导致服务和服务之间的强耦合）所谓的Saga，就是通过使用异步消息来协调一系列本地事务，从而维护多个服务之间的数据一致性。每个TXN是一个本地事务，当本地事务提交后，通过异步消息来告知下个服务开始执行其本地事务，以此类推。使用Saga是不考虑ACID的I（隔离性）的。此外，和使用分布式事务不同，每完成一个本地事务

服务间消息传递架构通常分为两种，一种是无代理消息架构（服务和服务之间直接传递消息），一种是基于代理的消息架构（服务把消息传递给消息代理，消息代理将消息再传递给接收方）无代理消息架构的优劣优势有着更低的延迟，无须经过代理避免了因为消息代理而出现的问题复杂度低，无须维护消息代理劣势必须使用服务发现机制来找到接收方消息无法保存，发送方和接收方必须同时在线代理消息架构的优劣优势发送方不需要知道接收方的位置，也不必关心接收方是否在线，只要将消息交给消息代理即可能够缓存消息，可以保持

服务的发现和注册有两种模式应用层服务发现模式这种模式下，服务端直接自己向注册中心进行注册（自注册模式），而客户端也直接通过查询注册中心获取服务实例的地址来调用服务（客户端有时可能会缓存服务实例）。这种模式的好处在于，他可以处理多平台部署问题，即如果在K8S上部署了一些服务，另一些服务在其他的遗留环境下，那么使用这种模式就能发现所有不同环境下的服务。而基于K8S的服务发现仅能发现部署在K8S下的服务。弊端在于需要为每种语言提供服务发现库，而且开发者需要自己负责和管理服务注册表。平台层服务发现模式

分层架构传统的mvc三层架构，上层依赖于下层，层与层之间有严格的界限。但是一旦业务庞大起来后，为了业务需要，就会增加新的层。新层往往有边界模糊等问题。此外，因为上层依赖于下层，当数据来源出现变更的时候（mysql专为redis或者es），数据源的切换，也会变得极为麻烦。六边形架构六边形架构有别于传统的分层架构，将上层对下层的依赖进行了依赖倒置，高层模块不再依赖低层模块，两者都依赖其抽象。通过适配器，将输入和输出都放到了设计的边缘部分。整个架构不再关心公开的是REST或者是GRPC，也不再关心从何处获

模式是针对特定上下文中发生的问题的可重用解决方案。常用的模式结构包含：需求结果上下文相关模式需求：必须解决的问题需求部分描述了必须解决的问题和围绕这个问题的特定上下文环境。需求之间可能会有冲突，所以必须把需求按照优先级进行排序。结果上下文：采用模式后可能带来的后果包含三个部分好处：这个模式的好处以及他解决了什么需求弊端：这个模式的弊端和他没有解决那些需求问题：这个模式锁引入的新问题相关模式：模式之间存在5种不同类型的关系前导：是催生这个模式的需求的模式。如微服务架构模式是

优势使大型的复杂应用程序可以持续交付和持续部署拥有持续交付和持续部署所需要的可测试性（因为服务小，自动化测试容易）拥有持续交付和持续部署所需要的可部署性（每个服务可以独立于其他服务进行部署）使开发团队能够自主且松散耦合（团队成员能够自由组合，负责部分业务）每个服务都相对较小且容易维护服务可以独立扩展每个服务都可以部署在适合他们需求的硬件上，选择最为合适的硬件。而单体架构选择的硬件必须满足所有的服务需求更好的容错性可以实现更好的故障隔离，某个服务中的内存泄漏不会影响到其他服务

智能管道类似A——ESB——B的架构应用A要访问服务B，A要先发数据给ESB，然后ESB调用B，B产生的数据返给ESB，然后ESB再返给A。ESB起到了类似于中间层的作用，对A的请求进行过滤和分发，之后再传递给相应的B获取响应；而B返回的响应先给ESB进行组合处理后再返回给A哑管道类似A——B的架构去掉了ESB中间层，微服务体系的管道只提供路由或者负载均衡之类的，不承载业务逻辑，或者是MQ之类的异步消息中间件，管道根本不关心具体传送的数据参考：参考文章...