一、背景
首先我们了解下计算机软件的发展历史,大概总结概括，分为c/s时代，web1.0时代和web2.0时代。
-
c/s时代:富客户端方案。卖软件可赚钱。例如 qq、影音、游戏。
-
1.0时代:主要是单向信息的发布，即信息门户—广大浏览器客户端 ，互联网内容是由少数编辑人员（或站长）定制的。
表是三大门户，新浪/网易/搜狐。新浪以新闻+广告为主，网易拓展游戏为主，搜狐延伸门户矩阵
-
2.0时代:注重用户的交互。每个人都是内容的供稿者。 RSS订阅扮演一个很重要的作用。
例如:博客、播客、维基、P2P下载、社区、分享服务
时至今日，互联网的形式演变已经变成全员参与，老少皆宜的活动。因此，互联网相关的技术也是要求越来越高，参与人数的增加也让系统的负担越来越大。
二、技术架构演进史
以下为2017年天猫双11的交易指标。那么大的数据量,那么快的处理请求，显然单台机器，单个服务绝对是无法支撑的。
那么怎么办呢，我们将原本单台部署，单台处理的服务，需要进行拆分以及部署到不同的服务器中去，使其用多台机器去处理，分担压力。但是我们又要保证系统的完整性。这就是分布式的设计。接下来我们看下服务架构的演进史。
三、架构演进一: 早期雏形
特征：应用程序主要做静态文件读取，返回内容给浏览器。
四、架构演进二: 数据库开发（LAMP特长）
特征：应用程序主要主要读取数据表值，填充html模块。业务逻辑简单，写sql
五、架构演进三: javaweb的雏形
特征：tomcat + servlet + jsp + mysql。一个war包打天下
项目结构：ssh/ssm三层结构。
六、架构演进四: javaweb的集群发展
特征：硬件机器的横向复制，对整个项目结构无影响。
七、架构演进五: javaweb的分布式发展
特征：将Service层单独分离出去，成为一个单独的项目jar。单独运行。Web服务器通过rpc框架，对分离出去的service进行调用。
八、架构演进六: javaweb的微服务发展
特征：从业务角度，细分业务为微服务，每一个微服务是一个完整的服务（从http请求到返回）。在微服务内部，将需要对外提供的接口，包装成rpc接口，对外部开放。
8.1、微服务概念
微服务架构之前还有一个概念：SOA（Service-Oriented Architecture，面向服务的架构）。人们逐渐认识到SOA可以用来应对臃肿的单块应用程序，从而提高软件的可重用性。它的目标是在不影响其他任何人的情况下透明地替换一个服务，只要替换之后的服务的外部接口没有太大的变化即可。
微服务应该算是SOA的一种演进。从 2014 年开始，得益于以 Docker 为代表的容器化技术的成熟以及 DevOps 文化的兴起，SOA的思想进一步演化，演变为今天我们所熟知的微服务。
微服务架构通过业务拆分实现服务组件化，通过组件组合快速开发系统，业务单一的服务组件又可以独立部署，使得整个系统变得清晰灵活。
8.2、微服务架构带来的挑战（没有银弹）
微服务架构虽然解决了旧问题，也引入了新的问题：
- 以往单体应用，排查问题通常是看一下日志，研究错误信息和调用堆栈，而微服务架构整个应用分散成多个服务，定位故障点非常困难
- 在微服务架构中，一个服务故障可能会产生雪崩效用，导致整个系统故障
- 服务数量非常多，部署、管理的工作量很大。
8.3 、微服务架构
微服务架构，核心是为了解决应用微服务化之后的服务治理问题。
应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：
解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：
以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：
当然微服务的服务治理还涉及很多内容，比如：
- 通过熔断、限流等机制保证高可用；
- 微服务之间调用的负载均衡；
- 服务调用链跟踪等等。
8.4、微服务框架
目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo，Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了Spring Cloud一些常用组件：
九、Service Mash
9.1、service mesh概念
使用统一的微服务框架有一个比较严重的问题：框架更新成本很高。每次框架升级，都需要所有应用服务配合升级。当然，一般会使用兼容方案，留出一段并行时间等待所有应用服务升级。但是如果应用服务非常多时，升级时间可能会非常漫长。并且有一些很稳定几乎不更新的应用服务，其负责人可能会拒绝升级……因此，使用统一微服务框架需要完善的版本管理方法和开发管理规范。
Service Mesh 通过 SideCar 代理转发请求，把微服务框架的相关实现全部集中到 SideCar 中，并通过 Control Plane 控制 SideCar 来实现服务治理的各种功能，这种业务与框架功能解耦的思能够解决框架更新成本高的问题。
Sevice Mesh相比于微服务框架的优点在于它不侵入代码，升级和维护更方便。它经常被诟病的则是性能问题。即使回环网络不会产生实际的网络请求，但仍然有内存拷贝的额外成本。另外有一些集中式的流量处理也会影响性能。
9.2、service mesh实现
Istio 是由 Google、IBM、Lyft 等共同开源的 Service Mesh（服务网格）框架，作为云原生时代下承 Kubernetes、上接 Serverless 架构的重要基础设施层，于 2017 年开始进入大众视野。
文章来源：https://www.toymoban.com/news/detail-425643.html
十、总结
本章主要讲了一下技术演进史。那么有一些问题留给大家。单机系统拆分成分布式和微服务，可能会遇到哪些问题，又该如何解决？欢迎评论区讨论。文章来源地址https://www.toymoban.com/news/detail-425643.html
附录
- 微服务入门这一篇就够了
到了这里，关于【架构】互联网应用开发架构演进历程的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
