了解微服务之前首先了解一下以下几点
单体应用的痛点：
部署效率低下、团队协作开发成本高。
什么是服务化
把传统的单机应用中的本地方法调用,改造成通过RPC、HTTP产生的远程方法调用把模块从单体应用中拆分出来,独立成一个服务部署。这样，各个模块就可以独立开发、测试、上线和运维 ,可以交由专业的团队来做,与主模块不耦合。
其次了解 以下内容
什么是微服务
一种架构风格。
开发单个应用作为一系列小型服务的套件,其中每个服务都运行在自己的进程中,并且通过轻量级的机制实现彼此间的通信这通常是HTTP资源API
这些服务是围绕着业务功能构建的,并且可以通过完全自动化的部署机制进行独立部署
这些服务的集中式管理做到了最小化(例如docker相关技术) ,每一种服务都可以通过不同的编程语言进行编写,并且可以使用不同的数据存储技术
微服务的特点：
组件以服务形式来提供
产品不是项目
轻量级通信、独立进程
分散治理、去中心化治理
容错性设计
会带来团队组织架构的调整
微服务特点
服务简单、便于学习和上手,相对易于维护
独立部署,灵活扩展.
技术栈丰富(语言多种、中间件多种、数据库多种)
自动按需扩展
根据CPU负载程度、特定时间(比如周末)、消息中间件的队
列长度、业务具体规则、预测等来决定是否扩展
自动分配一个新的服务实例,提高可用性
提高了可伸缩性(双11之后,自动减少服务器)
微服务有两大门派
Spring Cloud :众多子项目
dubbo :高性能、轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡以及服务自动注册和发现。=》dubbo提供的能力只是Spring Cloud的一部分子集
通信协议对比
RPC vs REST
服务提供方与调用方接口依赖方式太强(RPC)
服务对平台敏感,难以简单复用(RPC)
关于项目拆分项目
不适合拆分的情况
小团队,技术基础较薄弱
流量不高,压力小,业务变化也不大
对延迟很敏感的低延迟高并发系统
什么时候进行服务化拆分
第一阶段的主要目标是快速开发和验证想法
进一步增加更多的新特性来吸引更多的目标用户
同时进行开发的人员超过10人,这个时候就该考虑进行服务化拆分了
服务化拆分的两种姿势
纵向拆分【业务拆分】：功能独立、关联程度紧
横向拆分：比如用户服务，提供给各个模块