微服务总体技术架构体系

为数以亿计的用户提供优质的视频服务的爱奇艺技术产品团队，为了适应业务的快速迭代和创新，并支撑海量的用户请求，很多团队都对各自的业务系统自发地进行了微服务架构的改造。

微服务架构是一种将的软件设计方法，每个服务围绕特定业务能力构建，通过轻量级通信机制协同工作。

Git操作 版本控制 什么是版本控制？我们为什么要关心它呢？版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统 为什么要使用版本控制?软件开发中采用版本控制系统是个明智的选择。 有了它你就可以将某个文件回溯到之前的状态，甚至将整个项目都回退到过去某个时间点的状态。就算你乱来一气把整个项目中的文件改的改删的删，你也照样可以轻松恢复到原先的样子。但额外增加的工作量却微乎其微。 你可以比较文件的变化细节，查出最后是谁修改了哪个地方，从而找出导致怪异问题出现的原因，又是谁在何时报告

体系化认识微服务之三：微服务总体技术架构 这篇文章，介绍下微服务的总体架构体系，微服务拆分后涉及的服务众多，我们从一个全局的视角看下微服务架构涉及哪些方面。从上层到下层依次分为：接入层、网关、业务服务层、支撑服务层、平台服务层、基础设施层 技术构架总览： 接入层 接入层是入口，比如支付宝，接入层包括手机APP、Web、H5，是流量的入口，负责把外部的流量接入到系统的内部。 网关 ...

对于微服务架构（nacos）一些初步学习

1. 注册中心 主流技术栈：Zookeeper、Eureka、Consul、Nacos Zookeeper:多用于Dubbo，leader+follower，leader写同步到follower，follower可以读。CP，leader崩溃的时候，为了保证数据一致性，要重新选举leader以及数据同步，集群可能会短暂不可用； Eureka:多用于Spring Cloud NetFlix，peer-to-peer，每个节点都能读都能写，异步复制。AP，不同的节点可能读到的数据不一样，任何节点宕机，..

摘了了一下常见的微服务技术框架，仔细看一下，其实微服务离我们很近很近。在日常的开发中我们距离微服务架构缺少的只是微服务的治理部分。不过我觉得这未必是一件坏事，微服务架构本身就应该合理控制架构的规模，避免架构本身的治理工作超过业务本身提供的服务。

各大产品模块基本遵循了一致的技术实现路线，即前后端分离技术。后端服务底层基于Dubbo微服务框架和主备MySQL数据库，由Provider层提供RPC服务，Controller对外暴露Restful API，两者通过分布式部署和多活机制保证各大产品服务高可用扩展性。前端开发基于VUE框架，遵循统一的产品UI风格和用户体验。技术架构路线如下图所示：...

微服务架构简单说就是将一个完整的应用（单体应用）按照一定的拆分规则拆分成多个不同的服务， 每个服务都能独立地进行开发、部署、扩展。服务于服务之间通过注入RESTful api或其他方式调用。...