文章目录(一)发展历史；1 )前言；2 )单体体系结构；3 )集群及垂直化；4 ) SOA；5 )微服务体系结构；2 )微服务体系结构带来的挑战；优势；2
(一)发展历史；(一)前言
当前，非常复杂和大型的体系结构无疑随着业务产品中用户的数量和数据量的增长而发展。 体系结构的发展可能经历单体体系结构、垂直和集群、面向服务的体系结构(SOA )、微服务体系结构等。 当然，并不是所有公司都严格按照这种体系结构的顺序进化。 每个公司面临的问题不同，体系结构的发展过程也不同。 后端体系结构面临的挑战将会很大，特别是在互联网公司的体系结构中，如果用户数量呈爆炸式增长。 处理方法必须先承担流量，然后在流量稳定后再优化体系结构。
)2)单体架构【特征】
通常，如果一个war包或jar包包含一个APP应用程序的所有功能，则此体系结构称为单元体系结构。
许多传统的互联网公司和创业型公司在早期就采用了这样的架构。 因为该体系结构足够简单，可以快速开发和上线。 此外，在项目初期用户较少的情况下，这种体系结构足以支持业务正常运营。
【提问】
1、用户数量增加，网站访问量增加，后端服务器负荷增加。
2、用户越来越多，产品需要满足不同用户的需求才能留住用户，业务场景不断增加，变得复杂。
3、这意味着业务场景越来越复杂，单个包的部署升级也变得更加困难。 mld硬盘只需更新一种方法的影响是，必须重新测试和部署整个软件包。 如果一个封装有数百米或千兆字节的大小，部署过程也非常痛苦
(3)集群和垂直)1)通过横向增加服务器，使一台机器成为多台机器的集群。
)2)按业务垂直区域划分，减少业务耦合度，减少单个war包带来的可伸缩性问题。
)4) SOA 【SOA场景说明】
如果某个用户执行订单操作，系统处理逻辑前往库存子系统检查商品库存，并仅在库存充足时提交订单，则此库存检查逻辑是放入订单子系统还是放入库存子系统整个系统中一定有很多类似的共享业务场景。 这些业务场景的逻辑一定会重复创建，生成非常多冗馀的业务代码。 这些冗馀代码的维护成本随着时间的推移越来越高。 能否将这些共享业务逻辑分离开来，形成可复用服务？
一个集团公司下有许多子公司，每个子公司都有自己的业务模式和信息沉淀，没有在每个子公司之间进行交互和共享。 此时，各子公司可以创造一定的价值，但由于各子公司之间的信息不相互连接，相互形成信息孤岛，无法实现价值最大化。
【应用】
基于这些问题，引入了面向服务的体系结构(SOA )。 从意义上说，这与面向过程、面向对象、面向组件的思想相同，是软件构建和开发的方法。 中心目标是将由多个上层服务调用的公共共享业务提取到独立的基础服务中，这些提取出的共享服务是相对独立的、可重用的。 因此，在SOA中，服务是最核心的抽象手段，业务分为几个粗粒度的业务服务和业务流程。
SOA要解决的主要问题
1、信息孤岛。
2、共享业务复用。
)5)微服务机制【基本介绍】
从名称上看，面向服务(SOA )和微服务本质上是服务化思想的体现。 如果说SOA是面向服务开发思想的雏形，那么微服务是对可复用业务服务的更进一步的优化，SOA可以被视为微服务的超集。 也就是说，多个微服务可以构成一个SOA服务。 随着服务粒度的细分，本来10个服务可能被划分为100个微服务，随着服务规模的扩大，服务的构建、公共运维的复杂性也将加倍，因此实施微服务需要以软件提供链接和基础设施的成熟为前提因此，微服务对我来说不是新概念，本质上是服务化思想的最佳实践方向。
【SOA和微服务的区别】
由于SOA和微服务的关注点不同，两者有非常大的差异
SOA关注服务的复用性和孤立信息问题的解决。
微服务关注去耦。 去耦和复用性从特定的角度看是相同的，但本质上是不同的。 去耦是降低业务之间的耦合度，复用性关注服务的复用
微服务经常关注DevOps的持续提供。 在服务粒度细分后，开发运维更加重要，因此微服务与容器化技术的结合将更加紧密。
(二)微服务体系结构带来的挑战)一)通过更精细地划分优势复杂度可控：共享业务服务，一个服务只需要关注特定业务领域，通过定义合适的接口来明确表达服务边界由于体积小、复杂度低，开发、维护更简单。
技术选择更加灵活的：微服务由不同团队维护，可根据业务特性自由选择技术堆栈。
增强的可扩展性：可以根据每个微服务的性能要求和业务特性灵活地扩展服务。 例如，通过增加单个服务的群集规模，可以提高部署该服务的节点的硬件配置。
独立部署：是一个针对每个微服务独立运行的过程，因此可以独立部署。 如果微服务发生了更改，则不需要重新编译和部署整个APP应用程序，而且单个微服务的代码量很少，因此更容易发布
加高效。容错性:在微服务架构中，如果某一个服务发生故障，我们可以使故障隔离在单个服务中，其他服务可以通过重试、降级等机制来实现应用层面的容错
（2）挑战故障排查:一次请求可能会经历多个不同的微服务的多次交互，交互的链路可能会比较长，每个微服务会产生自己的日志，在这种情况下如果出现一个故障,开发人员定位问题的根源会比较困难。
服务监控:在一个单体架构中很容易实现服务的监控，因为所有的功能都在一个服务中。在微服务架构中，服务监控开销会非常大，可以想象一下，在几百个微服务组成的架构中，我们不仅要对整个链路进行监控，还需要对每一个微服务都实现一套类似单体架构的监控。
分布式架构的复杂性∶微服务本身构建的是一个分布式系统，分布式系统涉及服务之间的远程通信，而网络通信中网络的延迟和网络故障是无法避免的，从而增加了应用程序的复杂度。
服务依赖:微服务数量增加之后，各个服务之间会存在更多的依赖关系，使得系统整体更为复杂。假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，再部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，需要协调多服务的改变很少。
运维成本:在微服务中，需要保证几百个微服务的正常运行，对于运维的挑战是巨大的。比如单个服务流量激增时如何快速扩容、服务拆分之后导致故障点增多如何处理、如何快速部署和统一管理众多的服务等。
（3）微服务基本架构