FLGB

在之前安装的中都是单节点，集群不具有高可用性。

（如果是一个节点搭建的伪集群，会报端口冲突）ke 库用来储存元数据。如未安装kafka，

Kafka2.2.0 基于zookeeper搭建，这里也搭建一个三个节点的集群。

为保证集群高可用，Zookeeper 集群的节点数最好是奇数，最少有三个节点，所以这里搭建一个三个节点的集群。

假设最大 QPS 为 800 ，当压测工具每秒发起 1000 个请求的时候，只有 800个可以同时被处理，200 个在排队被阻塞住。16 核 32G,物理机，高峰期每秒几千（三四千的时候，网络负载比较高，CPU 使用率比较高，I/O 负载比较高）请求问题不大。每秒并发在1000 以内，每个服务部署 2 台机器，每台机器 4 核 8G，每台机器抗几百请求一点问题都没。配置 8核 16G 单台，16 核 32G，每台机器每秒钟的请求支撑几千绝对没问题，可以支撑上千个服务。

ACID 是数据库事务完整性的理论，CAP 是分布式系统设计理论，BASE 是 CAP 理论中 AP 方案的延伸。

云计算是大势所趋，今天信息系统建设的概念和观念，在较长尺度的“明天”都是会转变成适应云端的。Serverless+API 的这种设计方式，随着云计算的持续发展，将会成为一种主流的软件架构形式，无服务到时候也应该会有更广阔的应用空间。如果说微服务架构是分布式系统这条路当前所能做到的极致，那无服务架构，也许就是“不分布式”的云端系统这条路的起点。今天，我们已经能初步看见一些使用无服务的云函数去实现微服务架构的苗头了，所以把无服务作为技术层面的架构，把微服务视为应用层面的架构，这样的组合使用也是完全合理可行的。

保密是有成本的，追求越高的安全等级，我们就要付出越多的工作量与算力消耗。就连国家保密法都会把秘密信息划分为秘密、机密、绝密三级来区别对待，可见即使是信息安全，也应该有所取舍。

云原生（Cloud Native）是一种关注于在云环境中构建、部署和管理应用程序的方法和理念。云原生应用能够最大程度地利用。这个概念涵盖了许多方面，包括和团队文化等。

SOA 架构过于严谨精密的流程与理论，导致了软件开发的全过程，都需要有懂得复杂概念的专业人员才能够驾驭。从 SOA 诞生的那一天起，就已经注定了它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格来推广，注定会被微服务架构所取代。

烟囱式架构（Silos Architecture）是一种中间产物，通常出现在从单体架构向面向服务架构（SOA）过渡的过程中。它指的是将单体应用程序的不同功能或模块拆分成独立的“烟囱”，每个烟囱专注于特定的业务领域或功能区域。每个烟囱可以是一个独立的模块或子系统，其内部包含自己的业务逻辑、数据存储和用户界面。但是烟囱式架构通常仍然是一个单块应用，虽然它在内部可能分为不同的功能模块，但它们仍然是一个整体，还需要整体部署。

单体结构不是垃圾，不要被微服务过分渲染所蒙蔽单体架构在一些小规模、简单应用场景中具有一定的适用性，特别是对于刚开始的项目，它可以帮助团队更快速地推出产品。在公司业务发展一定阶段后，需要更高可扩展性、更灵活的部署和更好的模块化的情况下，考虑使用其他架构模式可能更合适。分布式、模块化的架构模式才是比较好的选择。

每个团队应该专注于特定的业务领域，具有相关的技能和能力。这有助于实现更快速的开发、更敏捷的响应和更好的业务对齐。决策和治理应该在不同的团队之间分散进行，而不是集中在单一的中央团队。将软件系统拆分为独立的服务，每个服务代表一个特定的业务功能或组件。系统应该能够随着业务需求的变化而演化，而不是一开始就设计出完美的解决方案。将开发视为持续的产品交付，而不是短暂的项目。这鼓励团队对其开发的产品负责，并关注长期的价值交付。自动化基础设施的配置、部署和管理，以提高开发、测试和部署的效率，并减少人为错误。

专业的服务注册发现框架，如Eureka和Nacos，提供了更多的功能和灵活性，能够更好地满足微服务环境中的动态性和管理需求。传统的DNS服务器和负载均衡器在一些情况下可能仍然有用，但专业的服务注册发现框架可以更好地满足微服务架构中的动态性和管理需求。虽然DNS服务器在服务发现方面存在一些限制，但在某些情况下仍然可以作为一种简单的服务发现机制。负载均衡器作为服务发现机制适用于一些较简单的情况，特别是当服务实例数量相对稳定，并且变动不频繁时。它可以提供基本的负载均衡和健康检查功能，适用于一些中小规模的应用。