1-架构演变

1.系统架构演变

        互联网产业发展的趋势越来越大，c端用户增加成几何倍数，需求性能复杂，传统行业也走转型互联网线上，此时，对技术上的要求越来越高，所以框架的功能，升级，高可用，越来越重要，框架结构主要进化过程：单体应用--》垂直拆分--》分布式服务--》soa服务治理--》微服务架构

1.1. 集中式架构

当网站的访问量不多时候，只需一台机器，一个实例，将所有功能都部署在一起。这种需求项目用于简化增删改查工作量的数据访问框架(ORM) 就可以完成项目开发。

存在的问题：

• 代码耦合度高，开发冲突行不方便

• 无法针对不同模块进行针对性优化

• 无法水平集群扩展

• 并发高可用低，有单点故障风险

1.2.垂直拆分

当qps逐渐增大，单体应用无法满足访问需求，此时为了应对更高的并发和功能模块变多，业务需求，我们根据业务功能对系统进行拆分：

优点：

• 系统拆分实现了请求 路由，解决了并发问题

• 可以针对不同模块进行开发迭代互不干扰

• 方便水平集群，负载均衡，容错率提高

缺点：

• 系统间相互独立，批次调用方法不方便，公共的方法抽取比较麻烦

1.3.分布式服务

 

当单体模块应用越来越多，应用之间的依赖接口调用越来越多，将核心公共接口抽离出来，作为独立的服务，形成服务注册调用中心的概念，前后端分离，使得前端可以根据市场体验开发，后端不用改动，所以服务的发现，调用，集群，熔断，限流是关键

优点：

• 将公共服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

• 系统间耦合度变高，调用关系错综复杂，难以维护

1.4.微服务

SOA，英文翻译过来是面向服务。微服务，似乎也是服务，都是对系统进行拆分。因此两者非常容易混淆，但其实缺有一些差别：

微服务的特点：

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

• 微：微服务的服务拆分粒度比较小，小到页面级别，例如一个用户管理就可以作为一个服务。每个服务虽小但是架构体系健全。

• 面向服务：面向服务是说每个服务都要对外暴露Rest风格服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。

• 自治：自治是说服务间互相独立，互不干扰

  • 团队独立：每个服务都是一个独立的开发团队，人数不能过多。

  • 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉

  • 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口

  • 数据库分离：每个服务都使用自己的数据源

  • 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

  •