Server架构：单体>集群>分布式>微服务>容器化
一、Server架构
1、架构演进
单体>集群>分布式>微服务>容器化
高可用、高并发、高性能
SpringBoot、MyBatis（MyBatis是一款基于Java的持久化框架）、Redis、Nginx、 ES搜索引擎（Elasticsearch是一个分布式、开源的搜索和分析引擎）、Service Mesh架构
Spring Boot可以使用MyBatis作为持久层框架，Redis可以作为Spring Boot应用程序的缓存存储，Nginx可以作为反向代理服务器来负载均衡和缓存Web请求，ES搜索引擎可以作为微服务架构中的数据存储和搜索引擎，Service Mesh可以用于微服务之间的通信管理。这些技术可以根据应用场景的需要灵活组合和使用。
1.1 单体架构（Monolithic Architecture）
单体架构：
尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用。其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变的无法完成。
我们应对的思路： 化繁为简，分而治之
1.2 集群（Cluster Architecture）
为了提高单体架构的可靠性和性能，集群架构出现了。
集群架构是将多个相同的应用程序部署在多个服务器上，通过负载均衡等技术将流量分发到不同的服务器上，以实现更高的可靠性和性能。
常见的负载均衡技术包括以下几种：
硬件负载均衡器；软件负载均衡器；DNS负载均衡
1.3 分布式架构（Distributed Architecture）
分布式架构（Distributed Architecture）：
1.4 微服务
微服务：围绕业务功能构建的，服务关注单一业务，服务间采用轻量级的通信机制，可以全自动独立部署，可以使用不同的编程语言和数据存储技术。
微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活：
- 原子服务
- 独立进程
- 隔离部署
- 去中心化服务治理
缺点：
- 基础设施的建设、复杂度高
微服务不足：
- 微服务应用是分布式系统，由此会带来固有的复杂性。开发者不得不使用 RPC 或者消息传递来实现进程间通信；此外，必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。
- 分区的数据库架构，同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库，从而对开发者提出了更高的要求和挑战。
- 测试一个基于微服务架构的应用也是很复杂的任务。
- 服务模块间的依赖，应用的升级有可能会波及多个服务模块的修改。
- 对运维基础设施的挑战比较大。
Service Mesh则是一种基础架构层，用于处理微服务架构中的服务间通信问题。
目前比较流行的Service Mesh包括Istio、Linkerd、Envoy等。这些Service Mesh实现了一个基础架构层，通过注入代理来实现服务间通信控制和观察。
二、云原生(Cloud Native)
Cloud Native 的4个要点：
DevOps /持续交付/微服务架构/容器化
微服务设计
服务组件化
三、API Gateway
2、LAMP —— MEAN
Linux 、Apache、MySQL、PHP(Python、Perl)
