Intro#从最早的html学习到单体应用到微服务架构的迁移，网站架构一直在变化，所以想写一篇关于网站架构变化的文章。单服务器#我们最早的网站只有一台服务器，网站应用+数据库+网站文件都在同一台服务器上，有时一台服务器上有多个网站。这个阶段除了WebServer，还会在服务器上安装一个数据库服务器。网站文件一般存放在网站目录下为单机数据库服务器+网站服务器#数据库和应用分离，数据库使用独立的数据库服务器。在网站服务器上只有网站，没有安装数据库服务器。一般网站服务器的瓶颈在内存和CPU，而数据库服务器的瓶颈多在IO。因此，分离之后，我们在网站服务器扩容的时候，可以多注意增加服务器内存和加入多核处理器。您可以更专注于改进服务器IO。数据库服务器+网站服务器+文件服务器#这一阶段在上一阶段的基础上进一步分离文件，使得网站迁移时网站上传的文件不需要迁移，文件服务器升级时也不需要迁移,存储常提高容量网站集群+负载均衡#当网站发展到一定规模时，我们可能会遇到一些系统瓶颈。除了升级服务器配置，我们还可以做网站集群，因为之前想过单台服务器配置可以升级到一定程度，升级成本会很高。相比之下，构建网站集群将更具成本效益且更具可扩展性。而且做集群可以防止单点故障导致网站不可用。由于是集群，所以很容易让多台服务器同时工作。我们将遇到哪个服务将处理请求的问题。一般我们会在网站集群前面加一个负载均衡器，负载均衡器会根据一定的负载均衡算法+负载均衡+分布式缓存来选择要处理的网站服务器#上面我们介绍了网站集群+负载均衡。对于服务器session，可以指定IP_Hash或者类似的负载均衡策略，但是如果不支持IP_Hash类的负载均衡算法，则需要支持分布式session的支持。一般DistributedSession可以借助分布式缓存来实现，可能会有一些内存缓存。如果使用网站服务集群，必须考虑使用分布式缓存，否则会导致数据不一致。一个服务器的缓存数据更新了，其他缓存数据还是老数据，会造成很多问题，所以需要引入网站集群+负载均衡+分布式缓存+数据库读写分离#数据达到一定规模后，数据库很容易成为系统的瓶颈。除了引入缓存来解决之外，我们可以将数据库与读写分离，读操作从库中进行，写操作从主库中进行。单体应用，从面向服务的架构开始，开始真正从单体架构迁移到分布式架构。当单体应用发展到一定程度，应用的复杂度越来越高，代码耦合度也会逐渐增加。从项目来看，项目越来越大，项目维护会越来越困难，冲突也会越来越多，项目加载、编译、运行的时间越来越长越来越长。从部署的角度来看，不同的API会相互影响。我只改了某个API，但是部署的时候只能更新。于是服务化应运而生。服务化将原来的单体架构拆分为分布式架构。每个服务只负责自己相关的业务逻辑。每一个服务都是一个小单体微服务架构#微服务架构1.0#在服务化的基础上进一步演进了微服务架构。微服务是服务的进一步发展，微服务是“ESB”更细化的服务。提倡将单一的应用程序拆分成一组小的服务，服务之间相互协调配合，为用户提供最终的价值。每个服务都运行在自己独立的进程中，服务之间通过轻量级的通信机制相互通信（通常是基于HTTP的RestfulAPI）。每个服务都是围绕一个特定的业务构建的，可以独立部署到生产环境、类生产环境等。另外，应该尽量避免统一集中的服务管理机制，针对具体的服务，应该基于业务上下文，选择合适的语言和工具来构建它”----MartinFowler的博客当项目转化为服务时，这个过程不是一蹴而就的，是一记耳光就成功了.把项目变成服务，需要解决很多问题，比如：服务之间怎么调用？订单服务要调用商品服务的数据，怎么调用？如何调用更稳定高效?【服务调用技术】服务之间如何负载均衡?订单服务需要调用商品服务，商品服务可能有很多，如何负载均衡【负载均衡技术】服务是如何管理的？如何定位服务？出现故障怎么办？【服务注册与发现技术】如何监控故障？微服务系统中有很多业务模块和组件，不同组件的指标不一样，那么如何监控这些组件【监控技术】如何定位故障？在微服务架构中，一个用户的请求会涉及到对多个内部服务的调用，那么如何定位问题呢？【LinkTracking技术】如何分析处理日志？业务模块多了，日志也会多。如果您直接查看日志文件，则不会显示它们。那么如何分析和查找日志呢？【日志分析技术】权限管理？微服务拆分服务后，很多服务都会对外暴露接口。这些接口如何进行统一的权限处理呢？[网关技术]服务调用出现问题如何处理？当服务由于各种原因停止响应时，调用者通常会等待一段时间，然后超时或收到错误返回。如果调用链路比较长，可能会导致请求堆积，整个链路占用大量资源，一直在等待下游响应。如何解决？【服务熔断、降级、限流】微服务架构2.0#基于Kubernetes+ServiceMesh的云原生微服务架构理念，通过SideCar（边车）实现对应用的一些非侵入式管理，让服务治理更加通用。借助ServiceMesh，可以更方便地管理服务间调用，更好地做流量控制等溯源，服务网络Lattice可以从无到有分为三个演进阶段（见下图）。第一阶段，每个服务都有自己独特的技能，自己处理对外通信。第二阶段，所有服务使用统一的类库进行通信。第三阶段，服务不再关心通信细节，一切都交给sidecar进程，就像在TCP/IP协议中一样，应用层只需要告诉TCP层要传输的内容，而TCP层负责在整个过程中保持所有内容的完整性，应用层不需要关心实际传输过程的任何细节。Kubernetes让微服务更容易。使用Kubernetes时，无需关注服务注册和发现。服务部署自动检测服务注册，无需在应用代码中向服务中心注册。Kubernetes使微服务扩展更容易。还可以根据应用的CPU等指标进行配置，用于实现应用的动态扩展。压力大时自动扩容，增加节点。当压力较低时，服务节点自动伸缩，减少服务节点数量。更多#一切不务正业的架构设计都是耍流氓。架构不是一蹴而就的，架构是演进的。如果这篇文章对你有帮助，别忘了连打3个，点赞、转发、评论，我们下期再见！获取方式：点赞、评论、关闭~了解更多JAVA知识技能，关注并私信博主(666)
