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