ArchitectureEvolution传统单体应用架构十多年前，主流的应用架构是单体应用，部署形式是服务器加数据库。在这种架构下，运维人员会细心维护这台服务器，保证服务的可用性。单体应用架构面临的问题随着业务的增长，这种最简单的单体应用架构很快面临两个问题。首先，这里只有一台服务器。如果本服务器出现故障，如硬件损坏，将导致整个服务不可用；第二，当业务量增大时，一台服务器的资源很快就无法承载所有的流量。解决这两个问题最直接的方法就是在流量入口处加一个负载均衡器，让单个应用可以同时部署在多台服务器上，从而解决服务器的单点问题。同时，单体应用也具备横向扩展的能力。本文已收录在Github仓库，其中包括计算机基础、Java基础、多线程、JVM、数据库、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服务、设计模式、架构、校招和社招分享，etc.核心知识点，欢迎star~Github地址如果不能访问Github，可以访问gitee地址。giteeaddress微服务架构1.微服务架构向通用服务演进。随着业务的进一步增长，更多的研发人员加入团队，共同开发单体应用的功能。因为单体应用中的代码没有明确的物理边界，大家很快就会遇到各种冲突，需要人工协调，大量的冲突合并操作，开发效率直线下降。于是，大家开始将单体应用拆分成可以独立开发、独立测试、独立部署的微服务应用。服务通过API相互通信，例如HTTP、GRPC或DUBBO。领域驱动设计中基于限界上下文拆分的微服务架构，可以大大提高中大型团队的研发效率。2、微服务架构给运维带来挑战。应用程序从单体架构演变为微服务架构。从物理的角度来看，分布式已经成为默认选项。这时候，应用架构师不得不面对分布式带来的挑战。新挑战。在这个过程中，大家会开始使用一些分布式服务和框架，比如缓存服务Redis、配置服务ACM、状态协调服务ZooKeeper、消息服务Kafka，以及GRPC或DUBBO等通信框架、分布式跟踪系统。除了分布式环境带来的挑战，微服务架构也给运维带来了新的挑战。研发人员过去只需要运维一个应用，现在可能需要运维十个甚至更多应用，这意味着安全补丁升级、容量评估、故障诊断等工作量成倍增加。此时，应用分发标准、生命周期标准、观察标准、自动化灵活性等能力的重要性也更加凸显。云原生1.基于云产品架构一个架构是否云原生，取决于这个架构是否生长在云上。这是对“云原生”的简单理解。这种“长在云上”并不是简单的使用云IaaS层服务，比如简单的ECS、OSS等基础计算存储；但应该理解为是否使用云上的分布式服务，比如Redis、Kafka等，这些都是直接影响业务架构的服务。在微服务架构下，分布式服务是必不可少的。原来大家自己开发这样的服务，或者基于开源版本来运维这样的服务。云原生时代，企业可以直接使用云服务。另外两个不得不提的技术就是Docker和Kubenetes。其中，前者规范了应用分发的标准。无论是SpringBoot写的应用，还是NodeJS写的应用，都是以镜像的形式分发；而后者是基于前者的技术。它还定义了应用程序生命周期的标准。一个应用从启动到上线，到健康检查，再到下线都有一个统一的标准。2.应用生命周期托管有了应用分发和生命周期标准，云端可以提供标准化的应用托管服务。包括应用版本管理、发布、上线后观察、自愈等。比如对于无状态应用，底层物理节点故障完全不会影响研发，因为应用托管服务可以自动完成搬迁工作基于标准化的应用生命周期，应用容器会在故障物理节点下线。在新的物理节点上启动相同数量的应用程序容器。可见，云原生进一步释放了价值红利。在此基础上，由于应用托管服务可以感知应用运行时的数据，如业务流量并发、cpu负载、内存占用等，业务可以根据这些指标配置伸缩规则，然后平台执行这些规则，根据业务流量的实际情况增减容器数量，这就是最基本的自动伸缩——自动伸缩。这可以帮助用户避免在业务低峰期间限制资源，节省成本，提高运维效率。本文总结，在架构的演进过程中，研发和运维人员的关注点逐渐从机器上转移，希望机器更多地由平台系统来管理，而不是由人来管理。这是对Serverless的简单理解。本文部分内容摘自网络。最后给大家分享一个Github仓库。大斌编译的300多本经典计算机书籍PDF，包括C语言、C++、Java、Python、前端、数据库、操作系统、计算机网络、数据结构与算法、机器学习、编程生活等，你可以star一下，下次找书直接搜索就可以了，仓库持续更新~Github地址
