版权声明

• 本博客的内容基于我个人学习黑马程序员课程的学习笔记整理而成。我特此声明，所有版权属于黑马程序员或相关权利人所有。本博客的目的仅为个人学习和交流之用，并非商业用途。
• 我在整理学习笔记的过程中尽力确保准确性，但无法保证内容的完整性和时效性。本博客的内容可能会随着时间的推移而过时或需要更新。
• 若您是黑马程序员或相关权利人，如有任何侵犯版权的地方，请您及时联系我，我将立即予以删除或进行必要的修改。
• 对于其他读者，请在阅读本博客内容时保持遵守相关法律法规和道德准则，谨慎参考，并自行承担因此产生的风险和责任。
• 本博客中的部分观点和意见仅代表我个人，不代表黑马程序员的立场。

业务架构

单体模式

• 早期系统以单体业务为主，逐个业务线扩张，呈现为多个独立运行状态的 MVC（Model-View-Controller）架构。每个业务线可能对应着不同的系统，例如在电商领域可能包括 B2B（Business-to-Business）、B2C（Business-to-Consumer）、C2C（Consumer-to-Consumer）等业务模式。每个业务线都有自己独立的系统，而每个系统又有各自的维护团队。
  

• ⽅案：代理层设置不同的⼆级域名，如b2b.abc.com，b2c.abc.com，分发给不同的服务器

• 每个系统专注于处理特定业务领域，团队之间相对独立，有利于快速开发和迭代。然而，随着业务的不断扩张，这种架构也会带来一些挑战和问题。

  • 复杂性增加： 随着业务的发展，系统的复杂性逐渐增加。每个业务线的系统可能有重复的功能，但由于独立开发，这些功能可能以不同的方式实现，导致了代码冗余和维护困难。

  • 协同问题： 不同团队之间可能存在协同问题。当一个业务涉及多个系统时，需要确保它们能够有效地协同工作，而这可能需要更复杂的集成和通信机制。

  • 难以扩展： 在这种架构下，随着业务的不断扩张，添加新的功能或业务线可能会变得更加困难。新的需求可能需要修改多个系统，增加了开发和测试的工作量。

• 存在的问题：功能重复、数据不互通

中台战略

• 中台在2015由阿⾥提出，其实是阿⾥共享业务技术部的成型过程。
• 中台战略是一种企业管理和技术架构的策略，是“共享”理念在业务、系统、组织架构上的⼀种落地与实施。
• 中台战略的核心理念是将业务系统划分为前台和中台两个部分，分别负责不同的职责，以实现业务的快速创新和稳健运营。

1. 前台和中台： 中台战略将业务系统划分为前台和中台两个部分。前台主要关注用户体验、业务创新和客户交互，而中台则专注于业务逻辑、数据管理和基础设施。
2. 前台特点： 前台是用户直接接触的部分，包括用户界面、交互设计、产品功能等。前台需要灵活、创新，能够迅速响应市场需求和用户反馈。
3. 中台特点： 中台是业务逻辑和数据管理的核心，包括业务规则、数据模型、服务等。中台的设计追求通用性、标准化，以提供支持各业务线的共享服务。
4. 服务化架构： 中台战略通常采用服务化架构，将业务拆分为独立的服务。这些服务可以被不同的业务线共享，实现业务功能的复用和标准化。
5. 数据驱动： 中台强调数据的重要性，通过建设统一的数据管理平台，实现数据的集中管理和共享。这有助于提高数据质量、降低数据冗余，同时为业务智能决策提供支持。
6. 敏捷开发和创新： 中台战略通过解耦前台和中台，使得业务线能够更加独立地进行敏捷开发。前台可以快速响应市场变化，而中台提供的服务则为业务线提供了基础设施和支持。
7. 平台化思维： 中台战略鼓励企业以平台化思维进行运营，将中台打造成一个支持多业务线、多渠道的基础设施平台，实现资源共享和协同创新。

• 中台战略的实施有助于解决传统单体架构下的业务发展难题，提高企业对市场变化的适应能力。然而，中台建设也面临一些挑战，包括组织文化的转变、技术架构的升级和对人才的需求等。成功实施中台战略需要企业在战略层面、组织层面和技术层面都进行全面的转型。

---

中台战略下：

• 中台模式下，基础业务也下沉到技术部⻔，甚⾄通过技术反推业务正向发展。下层业务，变化不⼤的业务持续沉淀，接⼝像滚雪球⼀样越来越完善。上层业务，跟业务模式和运营产品有关的系统变化迅速，对底层接⼝封装组合即可

• 通俗讲，中台模式就好比一个多层次的蛋糕，中间是中台，比如技术部门，负责处理一些基础的业务和技术工作。在这个模式下，基础业务被下沉到技术部门，甚至通过技术手段来推动业务的发展。底层的业务就像是一些变化不大的东西，一直在那里不断积累和改进，就像雪球越滚越大。而在上层，与业务模式和运营产品有关的系统变化很快，但它们只需要封装和组合底层的接口，就能够迅速适应不同的业务需求。
  

1. 业务中台
   • 业务中台基于公共服务的沉淀，需要积累⼀些基础的业务服务。它包括订单管理、支付服务、商品管理等业务功能的通用化和标准化。通过业务中台，不同的业务线可以共享这些通用功能，实现业务功能的复用，减少重复开发，提高效率。业务中台的建设旨在降低业务线之间的耦合度，使得每个业务线更加独立和灵活。
     • 商品中⼼：商品、类⽬、sku、spu
     • 交易中⼼：订单、状态流转、条⽬、⽀付
     • 营销中⼼：促销、优惠券、活动
     • 会员中⼼：账户、基本信息、收发货地址、商铺商家信息
     • 仓储中⼼：仓库、库存
     • 物流中⼼：发货信息、⾃主物流或外部物流对接
2. 技术中台
   • ，。
   • 技术中台是电商系统中与业务⽆关的基础沉淀，包括基础服务、开发框架、运维工具等。它为业务中台和数据中台提供技术支持，技术类内容可以在各个团队之间共享，同时为整个系统提供一致的技术标准。
     • 基础架构：核⼼类库、公共框架、基础服务、服务治理框架
     • 中间件：分布式缓存、分布式消息、数据存储（，nosql）、分布式⽂件、分布式调度
     • ⾃动化运维：监控中⼼、资源管理、配置中⼼、发布中⼼、⽇志平台
     • ⾃动化测试：任务协同、基础测试、性能测试、接⼝测试、持续集成
3. 数据中台
   • 数据中台是电商系统中负责数据管理的核心部分。它致力于构建一致性、高质量、可信赖的数据基础设施。通过数据中台，不同业务线可以共享数据，实现数据的集中管理和共享。这有助于提高数据的质量，减少数据冗余，支持数据驱动的决策。数据中台还为业务提供了数据治理、数据分析和挖掘的支持。
     • 数据抽取：从，nosql，⽇志等各个来源提供抽取接⼝
     • 数据接⼝：为上层业务提供需要的定制化业务数据接⼝
     • 数据分析：⾏业分析与决策、数据驱动运营
     • ⼈⼯智能：⽤户画像、商品推荐
     • 可视化：数据⼤屏、信息展示、活动报表等
4. 服务接入层
   • 服务接入层是电商系统与外部服务或第三方服务进行交互的接口层。它可以是一组API（应用程序接口），也可以是其他形式的接口。服务接入层使得外部服务可以方便地接入电商系统，同时也为电商系统的不同业务线提供了接口访问。这有助于构建一个开放的生态系统，促进合作和创新。

去中台化

• "去中台化"是企业从中台化架构转向更加扁平化或去中心化的组织结构或技术架构。它出现在企业经历了中台化转型后，发现需要调整或改变原先中台化架构的情况下。

1. 简化架构：中台化架构过于复杂或不适用于其特定业务需求。因此，简化整个架构，减少中间层次和组件，使系统更加扁平化，以提高灵活性和效率。
2. 业务焦点重置： 中台化过程中，可能导致减少对业务的关注。去中台化可以使企业重新聚焦于业务需求，将更多精力放在满足客户需求和提高业务价值上。
3. 个性化服务和定制化需求： 部分行业或业务领域可能更需要个性化的服务或定制化的解决方案。去中台化可以使企业更专注于满足特定客户群体的需求，而不是过度依赖于中央化的服务和解决方案。

• 注意：去中台化并不代表放弃所有中台化所带来的技术优势，而是可能更注重各业务之间的紧密整合和创新。企业可能会采用更灵活的技术架构，以更好地支持不同业务线的创新和发展。

数据架构

单数据库架构

• 在单数据库架构中，整个系统使用一个单一的数据库来存储和管理所有的数据。这种架构形式相对简单，适用于小型和中型系统，尤其是对于一些规模较小的应用，如个人博客、小型企业管理系统等。
  

主要特点包括：

1. 集中管理： 所有数据都存储在一个数据库中，方便集中管理和维护。
2. 简单： 单数据库架构相对来说比较简单，搭建和维护成本相对较低。
3. 事务一致性： 由于只有一个数据库，事务管理相对较为简单，确保了数据的一致性。
4. 易于备份和恢复： 数据库备份和恢复相对容易，因为只需处理一个数据库。

单数据库架构的缺点：

1. 性能瓶颈： 数据库的读写负载瓶颈，导致性能下降。
2. 可扩展性有限： 单数据库的可扩展性有限，无法以应对更多用户或更大的数据量。
3. 单点故障： 单数据库是系统的单一数据存储点，一旦发生数据库故障，整个系统可能受到严重影响。
4. 复杂查询影响性能： 复杂查询可能影响数据库的性能，尤其在大规模数据集上执行复杂的联合查询。
5. 难以应对多样化需求： 单数据库架构可能无法灵活应对不同类型的数据存储需求。

主从读写

• 主从读写是一种常见的数据库架构设计，它将数据库服务器分为主服务器（Master）和从服务器（Slave）。这种架构主要用于提高系统的读取性能和容错能力。
  

1. 主服务器（Master）：

   • 主服务器负责处理所有的写操作（插入、更新、删除）。
   • 写操作将数据写入主数据库，并且主数据库负责同步更新到从服务器。

2. 从服务器（Slave）：

   • 从服务器主要用于处理读操作（查询）。
   • 从服务器定期从主服务器同步数据，以保持与主服务器的数据一致性。

3. 读写分离：

   • 主从读写架构的主要优势在于读写分离。由于读操作通常比写操作频繁，通过将读操作分发到从服务器，可以有效减轻主服务器的读取负载，提高整个系统的读取性能。

优势：

优势	详细说明
读性能提升	通过将读操作分发到从服务器，有效减轻主服务器的读取负载，提高整个系统的读取性能。
容错和高可用性	当主服务器发生故障时，从服务器可以接替主服务器的角色，确保系统的高可用性和容错能力。
数据备份和恢复	从服务器可以作为主服务器的备份，当主服务器数据丢失或损坏时，可以通过从服务器进行数据恢复。
读写分离	有效分离读写操作，提高系统的整体性能和响应速度。
资源有效利用	主从服务器分工明确，可以充分利用硬件资源，提高系统整体的效率。
延迟可接受	尽管存在一定的同步延迟，但对于对实时性要求不是非常高的应用，这种延迟是可以接受的。

劣势：

劣势	详细说明
写性能瓶颈	主服务器负责所有写操作，可能成为系统的写性能瓶颈，特别是在高写入负载的情况下。
同步延迟	由于从服务器需要定期同步主服务器的数据，可能存在一定的同步延迟，对于某些实时性要求极高的应用可能不够理想。
配置和管理复杂	主从读写架构需要进行配置和管理，确保主从服务器之间的数据同步正常，以及故障切换的机制得以正确配置。
一致性难保证	在主从同步的过程中，如果主服务器和从服务器之间的网络发生故障，可能会导致数据同步不一致的问题。
数据安全风险	从服务器可能成为攻击目标，需要采取额外的安全措施来保护数据的安全性。
可扩展性限制	对于某些需要极高可扩展性的应用，主从读写架构的扩展性可能受到一定限制，需要考虑其他更为分布式的数据库架构。

主从读写架构在提高系统读性能、容错和高可用性方面有很大优势，但也存在一些劣势，特别是在写入负载较高、对实时性要求很高、配置和管理要求复杂等方面。在选择数据库架构时，需要根据具体的业务需求和系统特点进行权衡。

注意，**主从读写架构对于提高读取性能是有效的，但对于写操作的性能提升并不明显。**在高写入负载的情况下，还可能存在主服务器的性能瓶颈。

分库分表

• 分库分表是一种常见的数据库架构设计，用于解决大规模应用中单一数据库的性能瓶颈问题。这种架构将数据库按照一定规则划分成多个库（Database）和表（Table），以提高系统的扩展性和性能。例如：主从库的写⼊依然是有⼀个统⼀的主库⼊⼝。随着业务量的提升，继续细粒度化拆分。
  • 业务分库：订单库，产品库，活动库，会员库
  • 横向分表：（拆记录）3个⽉内订单，半年内订单，更多订单
  • 纵向分表：（拆字段）name、phone⼀张表，info、address⼀张表，俩表id⼀致
• 分库：不同的数据库，所以⽆法使⽤数据库事务，⽽分布式事务的效果并不理想，多采⽤幂等和最终⼀致性⽅案。分表：拆了再聚合是⼀对⽭盾，例如按下单时间维度的分表，需要按⽤户排序统计变得异常困难。中间件：Sharding-JDBC，Mycat，Atlas
• 分库分表是一种在大规模数据应用中解决性能瓶颈问题的有效手段，但也需要在复杂性和管理成本之间进行权衡，根据具体的业务需求和数据特征做出明智的选择。

高速缓存

1. 数据库往往是系统的瓶颈，根据数据的冷热划分，热点数据如类⽬、商品基础信息放在缓存中，其他数据延迟加载
   • ehcache：⾮分布式，简单，易维护，可⽤性⼀般
   • memcache：性能可靠，纯内存，客户端需要⾃⼰实现，⽆持久化
   • redis：性能可靠，纯内存，⾃带分⽚，集群，哨兵，⽀持持久化，⼏乎成为当前的标准⽅案
   • MTD巨头⾼性能缓存代理⽅案实战，Twemproxy⾼阶使⽤）
2. 缓存策略：冷热数据的存放，缓存与的边界需要架构师去把控，重度依赖可能引发问题
   • 缓存陷阱：击穿（单⼀ key过期），穿透（不存在的 key），雪崩（多个 key 同时过期）
   • 数据⼀致性：缓存和 db 之间因为同⼀份数据保存了两份，⾃然带来了⼀致性问题

数据多样化

• ⼀个⽹站中，数据库和缓存只是⼀种基本的存储⼿段，除了这些，随着⽹站架构的发展还需要各种形式的存储结构
  
• 数据库全⽂检索→搜索引擎、本地上传+nfs→分布式⽂件系统的演进

分布式文件

• 分布式文件系统（Distributed File System）是一种将文件存储在多个节点或服务器上，以提供高性能、可靠性和可伸缩性的文件存储解决方案的系统。

  • hdfs(Hadoop Distributed File System)：主要用于存储大规模数据集，并且与Hadoop生态系统集成，为MapReduce作业提供高吞吐量的数据访问。
  • fastdfs：主要用于构建大规模的分布式文件存储系统，特别适用于存储图片、音频、视频等大文件。
  • cephFs：CephFS提供了面向文件的接口，适用于需要大规模、高性能分布式文件存储的场景。

• 总结

  • HDFS是专门为Hadoop生态系统设计的，适用于大数据处理。它使用分块存储和数据复制机制。
  • FastDFS专注于文件存储和访问，适用于构建大规模的分布式文件存储系统，如图片、音频、视频存储。
  • CephFS是Ceph存储系统的一部分，支持多种存储方式（块、对象、文件），具有很高的可扩展性和灵活性。

nosql

• NoSQL（Not Only SQL）是一类数据库系，提供了灵活的数据存储模型、高度的可扩展性和性能优势
  • redis：基于内存的数据存储系统，被广泛用作缓存、消息代理和数据库
  • mongodb：文档型数据库，使用类似JSON的BSON格式存储数据
  • hbase：分布式、面向列的NoSQL数据库，运行在Hadoop文件系统（HDFS）之上。
  • TiDB：分布式SQL数据库，结合了传统的关系型数据库和NoSQL的优势

搜索引擎

1. Lucene：Lucene是一个开源的全文搜索引擎库。

   • 用途： 它提供了强大的文本搜索和检索功能，可以被用于构建自定义的搜索引擎。
   • 特点： Lucene是一个Java库，为开发人员提供了搜索引擎的基本构建块。它不是独立的搜索引擎，而是一个用于构建搜索引擎的库。

2. Solr：Solr是一个构建在Lucene之上的开源企业搜索平台。

   • 用途： Solr简化了在应用中集成全文搜索和其他类似功能的过程。它提供了RESTful API，使得与各种编程语言和应用程序轻松集成。
   • 特点： Solr包含了一些附加功能，如分布式搜索、复制和负载均衡等。它支持多种数据格式，并提供了强大的查询和分析功能。

3. Elasticsearch： Elasticsearch也是一个构建在Lucene之上的开源搜索引擎。

   • 用途： Elasticsearch专注于实时数据分析和可视化，适用于日志、指标和全文搜索等场景。
   • 特点： Elasticsearch具有分布式特性，能够处理大规模数据。它提供了RESTful API，支持多种数据格式，还包括了丰富的聚合和分析功能。Elasticsearch被广泛用于构建实时搜索和分析引擎。

---

共同点

1. Lucene是搜索引擎的核心库，而Solr和Elasticsearch是构建在Lucene之上的应用。
2. Solr和Elasticsearch都提供了方便的HTTP接口，使得它们易于集成到各种应用中。
3. Solr和Elasticsearch都支持分布式架构，可以水平扩展以处理大规模的数据和请求。

---

区别

1. Solr更专注于企业级搜索，提供了更多的功能来满足企业需求，如复制、分片等。
2. Elasticsearch更专注于实时数据分析和可视化，适用于日志和指标等场景。它在聚合和分析方面提供了更强大的功能。

架构特点

• 开发框架⽀持：存储的数据多样化，要求开发框架架构层⾯要提供多样化的⽀撑，并确保访问易⽤性
• 数据运维：多种数据服务器对运维的要求提升，机器的数据维护与灾备⼯作量加⼤
• 数据安全：多种数据存储的权限，授权与访问隔离需要注意

应用架构

单机调优

• 早年间的项⽬⼤多采⽤mvc开发
  
• 每个项⽬成⼀个mvc结构，部署在应⽤服务器上（tomcat、jboss、websphere，weblogic）。
• 随着业务扩张，需求迭代，项⽬变得越来越⼤，⼀个war包动辄几百兆。

动静分离

• 早年间的Apache+tomcat，后被Nginx替代（前后端开发模式的演进：mvc页面嵌套→接⼝化）
  
• 优势
  • 静态响应：tomcat对静态⽂件响应⼀般，提取静态⽂件，直接由Nginx响应
  • 动态代理：后端api通过代理转发给tomcat应⽤机器
  • 开发层⾯调整：项⽬结构要同步调整，由原来的⼀体化mvc转换为后端api+前端形式。
  • 前后协调：前后端的分⼯变得更明确，互相并并行开发，独立部署，但也带来了接口协调与约定等沟通问题
  • 跨域问题：后段与前端如果域名不同，可能存在跨域问题（head头，jsonp等⼿段可以解决）。

SOA

• 单纯的动静分离只解决了自己服务的项⽬结构，跨项目接口调⽤时，必须经过rest请求，不利于服务之间的交互

• 公共服务：重复开发的基础服务提取出来，形成服务中心，避免重复造轮⼦，降低成本，架构团队出现。

• 独立性：各⾃服务独⽴部署升级，粒度更细，低耦合，高内聚

• SOA理念诞⽣：服务治理的范畴，重在服务之间的拆分与统⼀接口。SOA（Service-Oriented Architecture，面向服务的架构）是一种软件设计和架构风格，其主要思想是通过将软件系统划分为独立且松散耦合的服务单元，这些服务单元通过标准化的协议进行通信，从而实现应用程序的构建和整合。

• 技术⼿段

  • 异步化：rabbitmq、rocketmq、kafka
  • RPC：Dubbo、Zookeeper
  • RPC框架
  • 界限把控：服务的粒度、拆分和公共服务提炼需要架构师的全局把控。设计不好容易引发混乱
  • 部署升级：服务数量增多，⼈⼯部署变的不现实，必须借助⾃动化运维
  • 服务可⽤性：抽调的微服务因需要被多个上层业务共享，可⽤性等级变⾼，⼀旦down机就是灾难
  • 熔断和限流：做好服务熔断和限流，提防服务单点瓶颈造成整个系统瘫痪。短信提醒失败不要影响下单。

微服务

• 微服务是基于SOA思想，将系统粒度进⼀步细化而诞⽣的⼀种手段。中台化得以实现，各个中⼼以及前端业务拆解为多个小的服务单元

• 微服务经历了从1.0（cloud）到2.0的演化（service mesh），目前企业中主流的解决⽅案依然是cloud全家桶Spring Cloud Spring Cloud微服务前沿技术栈，Spring、Spring Boot。

• 服务拆分：粒度并非越小越好，太小会增加维护成本。

• 接口约束：系统增多，各个服务接口的规范化日益重要，要求有统⼀的服务接口规范，推动企业消息总线的建设。

• 权限约束：接口不是任意想调就可以调的，做好权限控制，借助oauth2等⼿段，实现服务之间的权限认证。

部署架构

单机部署

• 部署简单：采用web、jar包部署与发布，等资源同台机器连接，简单易操作。
• 资源争夺：在业务发展的初始阶段尚可支撑，随着访问量的上升，单机性能很快会成为系统瓶颈。

⻆⾊划分

• 稍微⼤⼀点的系统，把数据库、缓存、消息等中间件剥离出去，单独机器来部署
  
• 多台机器：tomcat与mysql各⾃独占机器资源
• 针对性扩容：tomcat应⽤机更注重cpu的运算和内存，mysql更注重io与磁盘性能，针对各⾃情况扩容
• 数据维护：可以抽出单独的dba来维护数据库服务器
• 数据安全：需要跨机器访问数据库，链接密码需要注意防范泄漏

应⽤集群

• 2004-2005，淘宝V2.0，EJB为核⼼。V2.1架构下，引⼊Spring框架⾛向轻量化和集群
  

• apache：早期负载均衡⽅案，性能⼀般

• Nginx：7层代理，性能强悍，配置简洁，当前不⼆之选

• haproxy：性能同样可靠，可做7层或4层代理。

• lvs：4层代理，性能最强，linux集成，配置麻烦

• f5：4层，硬件负载，财⼤⽓粗的不⼆选择

• session保持：集群环境下，⽤户登陆需要分布式session做⽀撑

• 分布式协同：分布式环境下对资源的加锁要超出线程锁的范畴，上升为分布式锁

• 调度问题：调度程序不能多台部署，容易跑重复，除⾮使⽤分布式调度，如elastic-job

• 机器状态管理：多台应⽤机的状态检测与替换需要做到及时性，⼀般niginx层做故障转移

• 服务升级：滚动升级成为可能，灰度发布

• 日志管理：⽇志⽂件分散在各个机器，促进集中式⽇志平台的产⽣

多层代理

• 机器规模进⼀步加⼤，动静态均有多个Nginx负载，⼊⼝统⼀交给lvs负载。多层代理形成。
• 机房受限：lvs依然是单⼀节点，即使keepalived做到⾼可⽤，流量仍然需要在唯⼀⼊⼝进⼊

异地访问

• 将相同的系统部署多份，分散到异地多个机房，或者电信、移动等多个⽹络中。不同地点，不同⽹络接⼊的⽤户，有了不同的访问⼊⼝和选择。
  
• dns轮询：通过配置多个ip将服务部署到多个机房，通过dns的策略轮询调⽤，可以实现机房层⾯的扩容
• CDN：就近原则，使⽤户获得就近的机房访问相关资源，投资太⼤，购买他⽅需要付费
• 基本解决了机器部署的扩容问题，随着业务的发展，扩容与收缩变得困难，促进资源调度层⾯的技术发展

云平台

• 针对中台化的建设及微服务数量的飙升，部署和运维⽀撑同步进⾏着变⾰。⾯临微服务的快速部署，资源的弹性伸缩等挑战，容器化与云被推进。
  

• 虚拟化：vm⽅案，Openstack，Vmware，VirtualBox

• 容器化：docker

• 编排：swarm，k8s，k3s（课题：运维篇 docker，k8s深⼊原理与应⽤）

• 云化：容器化解决了资源的快速伸缩，但仍需要企业⾃备⼤量机器资源。推动私有云到企业云进化

• 资源预估：注意资源的回收，降低资源闲置和浪费，例如⼤促结束后要及时回收。

• 运维要求：需要运维层⾯的⾼度⽀撑，⻔槛⽐较⾼

• 预估⻛险：云瘫痪的故障造成的损失不可估量

架构思想总结

1. 知行合一，确保技术决策与业务目标紧密一致
   • 在构建技术架构之前，首先要理解业务需求和问题的实质。技术应该服务于业务目标，而不是为了技术而技术
2. 原生优于定制，约定大于配
   • 尽量使用原生（标准）的解决方案，而不是进行过多的定制。同时，通过共识和约定来减少配置的复杂性
3. 控制技术欲，不要瞎折腾
   • 不要过度追求新技术，避免为了使用新技术而不加思考地改变架构。技术选型应该基于实际需求和业务场景，而非盲目跟风。
4. 留下扩展,，但要避免过度设计和过度优化。
   • 架构应该具有一定的扩展性，能够容纳未来的增长和变化。然而，也要在现实可预见的范围内进行规划。
5. 没有最好的，只有最合适的
   • 没有一种通用的、适用于所有场景的最佳解决方案。技术选择应该基于具体的需求、团队的技术栈和经验，以及系统的特定要求
6. 够用就好，玩的越花，风险越大
   • 在技术决策上要保持实用主义，选择足够满足需求的方案，避免过度投入。
7. 简约最美
   • 保持系统和代码的简洁性有助于提高可读性、可维护性，减少错误和降低复杂性。