一、服务架构模式演变：
1）集中式/单体应用架构：
当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。
前后端都在一个包里，所有的业务模块都耦合在一个项目里，大多数都是模块之间的调用，开发和部署都在一起；
单个模块有更新，所有模块一起启停，而且对高并发、大数据处理能力比较弱；
存在的问题：
代码耦合，开发维护困难；
无法针对不同模块进行针对性优化；
无法水平扩展；
单点容错率低，并发能力差；
2）垂直拆分
当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分：
优点：
系统拆分实现了流量分担，解决了并发问题;
可以针对不同模块进行优化;
方便水平扩展，负载均衡，容错率提高;
系统间相互独立;
缺点：
服务之间相互调用，如果某个服务的端口或者ip地址发生改变，调用的系统得手动改变；
搭建集群之后，实现负载均衡比较复杂；
3）分布式架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
此时，用于提高业务复用及整合的分布式调用是关键。
将一个大的系统拆分成多个子系统;
优点：
将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率；
缺点：
系统间耦合度变高，调用关系错综复杂，难以维护;
搭建集群之后，负载均衡比较难实现;
4）面向服务架构（SOA,service oriented architecture）：
基于分布式架构演变来的，俗称服务化，可以理解为面向于业务逻辑开发层。
将共同的业务逻辑进行拆分、拆分成独立一个项目进行部署，没有视图层。服务概念可以理解为接口。
将应用中相近的功能模块聚合到一起，以服务的形式提供出去，服务于服务之间通过接口进行通信，其是面向服务的；
5）微服务架构：
微服务架构基于SOA架构演变来的。
单体应用拆分成多个互不相干的小应用，每个小应用称为微服务。
服务与服务之间通过轻量级的通信机制（通常是基于http、RESTful Api）互相协作、配合；
每个服务都是围绕具体的目的/业务进行构建，并运行在独立的进程中，可独立部署，可以用不同的编程语言编写，并使用不同的数据存储技术。
二、应用服务部署方式演变
1）物理机原生部署：单台物理机安装OS→部署依赖环境→安装应用程序→重复以上步骤在其他物理机部署服务→调试→试生产→生产运营；
缺点：小时级别部署、硬件资源利用率低、成本投入大、物理机硬件限制软件平台、应用迁移复杂、扩展比较困难（纵向扩展受限）；
2）虚拟机部署：物理机虚拟化（分2种形式）→虚拟机安装OS及环境→部署应用→调试→试生产→生产运营；
优点：硬件资源池化使得硬件利用率提高、物理资源层面的隔离、不受硬件平台限制、扩展容易、方便对接云化、可将依赖环境的OS打包成一个镜像模板；
缺点：十分钟级别部署、系统消耗资源高（虚拟化及虚拟机操作系统占用资源）；
3）容器化部署：物理机或虚拟机安装OS→从仓库拉取并运行服务镜像→调试→试生产→生产运营； 优点：秒级部署服务，自动运维；
优点：秒级部署，APP层面的隔离、保证开发、测试、部署、调试、生产、运维的环境高度一致，统资源消耗低，简化配置、提升开发效率；
缺点：容器多时，管理比较困难；应用不能完全隔离；
常见的容器项目有：docker;
4）容器云部署： 在各厂家云平台上使用容器编排工具管理容器；
优点：K8S等工具实现容器编排及自动化运维；
缺点：K8S要求较高，出现问题排查难度大。
常见容器编排工具有：docker-swarm,K8S;