微服务入门介绍

目录

一、服务架构设计与发展

二、微服务简介

三、微服务架构工作流程

四、Spring Boot 介绍

---

一、服务架构设计与发展

---

【1】单体架构图，如下：

单体架构的特点和好处：
   ● 单一代码库、IDE友好、看着简单；
   ● 容易部署；
   ● 开发模型简单，一份代码库进行编码、构建和部署；
   ● 技术栈单一；
单体架构的问题：
   ● 庞大的代码库，关系错综复杂；
   ● 交付周期长；
   ● 扩展能力与弹性受限；
   ● 新技术与工具框架使用会受限；
   ● 维护成本高；

【2】服务化架构图，如下：

服务化架构的特点和好处：
   ● 对业务进行分层，通常分为表现层（前段）、公共服务、业务逻辑服务、数据访问层等；
   ● 对业务进行解耦，通过Pub-Sub或RPC进行服务器间调用关系解耦；
   ● 服务独立性，多数服务可以进行独立打包发布；
   ● 每个服务的技术栈单一；
   ● 部署简单，具有可伸展性；
服务化架构的问题：
   ● 对于部分服务而言，代码库依然很强大；
   ● 打包，发布和部署流程不足够好；
   ● 维护团队间沟通受阻，技术经验有效传递不够；
   ● 服务增多对开发人员不够友好；

【3】微服务架构：服务注册——>服务发现——>服务调用

【4】架构设计发展：MVC Services（视图、业务逻辑前后端分离），SOA（大型系统分层解耦，标准接口调用，分布式系统），Micro（云计算产物，关注敏捷交互和部署速度、频次）；

二、微服务简介

---

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。  

suite of small service：由一系列小服务组成；
running in its own process：每个服务运行于自己的进程；
built around business capabilities：围绕着业务功能进行建模；
independently deployable：每个服务可进行独立部署；
bare minimum of centralized managerment：最低限度集中管理；

【1】微服务的特征：
   ● 每个微服务都是业务完整的：接口及界面呈现、业务逻辑、数据管理；
   ● 每个微服务仅仅对一个业务负责：产品服务、评价服务、支付服务、订单服务；
   ● 每个微服务接口明确定义：接口消费只关注接口，对微服务不具备依赖；
   ● 独立部署、升级和伸缩；
【2】微服务的独立性关键词：
   ● 代码库独立；
   ● 技术栈独立；
   ● 可伸缩性、可扩展性独立；
   ● 业务功能独立；
【3】独立的代码库：每个微服务具备自己的代码库
   ● 由团队开发者维护；
   ● 编译、打包、发布及部署都很快；
   ● 服务启动迅速；
   ● 在各个服务的代码库间没有交叉依赖；
【4】技术栈对立：每个微服务都有自己独立的技术栈实现
   ● 根据业务实现需求来选择最适合的需求栈；
   ● 团队可以尝试新的技术、工具和框架；
   ● 所选的技术一般来说都是轻量级；
   ● 不需要同一标准化技术栈的选择。无需关注因技术选型而纠结业务的实现；
【5】独立的可伸缩性：每个微服务都可以独立伸缩
   ● 更加直观的定位性能的瓶颈；
   ● 数据库分片可根据需求来；
【6】业务功能独立：每个微服务可以在不影响其他微服务的情况下进行功能扩展
   ● 例如更新新版本界面或者某个微服务中的某项功能时，无需更新整个系统；
   ● 可以进行整个业务功能的重写，并替换之；
【7】微服务的优点：
   ● 每个服务足够内聚，足够小，代码容易理解，开发效率高；
   ● 服务之间独立部署，微服务架构让持续部署成为可能；
   ● 每个服务可以各自进行x扩展和z扩展，而且每个服务可根据自己的需要部署到合适的硬件服务器上；
   ● 容易扩大开发团队，可以针对每个服务组件自己的开发团队；
   ● 提高容错性（fault isolation），一个服务的内存泄漏，并不会导致整个系统瘫痪；
   ● 系统不能被长期限制在某个技术栈；

【8】微服务不足：
   ● 微服务应用是分布式系统，由此会带来固有的复杂性，开发者需要在RPC或消息传递之间选择并完成进程间通讯机制。此外，他们必须用代码处理消息传递过程中速度过慢或者不可用等局部失效问题；
   ● 开发人员需要处理分布式系统的复杂性：开发人员需要设计服务间的通信机制，对于需要多个后端服务的user case，要在没有分布式事物的情况下，实现代码非常困难；设计多个服务直接的自动化测试也具备相当大的挑战；
   ● 服务管理的复杂性：在生产环境要管理多个不同的服务实例，这意味着开发团队要统一统筹。(PS：现在docker的出现适合解决这个问题)；
【9】应用微服务架构的时机如何把握：对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错
【10】微服务架构的通信方式：
   ● PRC（Remote Proceduce Call）：支持 RPC 的微服务架构 Dubbo/Dubbox，基于 RPC 与平台有关；
   ● RESTful（Representational State Transfer）：支持 RESTful 的服务架构 Spring Cloud/Dubbox，基于HTTP与平台无关；
【11】什么样的项目适合微服务：微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。

三、微服务架构工作流程

---

【1】设计阶段：将产品功能拆分成若干个服务，为每个服务设计API接口；
【2】开发阶段：实现API接口（包括单元测试）实现UI原型（界面）；
【3】测试阶段：前后端集成，验证产品功能；
【4】部署阶段：发布测试环境，发布开发环境；

微服务本质：
（1）微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
（2）微服务的目的是有效的拆分应用，实现敏捷开发和部署 。
（3）微服务提倡的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

四、Spring Boot 介绍

---

【1】为什么使用 SpringBoot：
    ●  Spring Boot是为简化Spring项目配置而生，使用它使得jar依赖管理以及应用编译和部署更为简单。Spring Boot提供自动化配置，使用Spring Boot，你只需编写必要的代码和配置必须的属性；
    ●  使用Spring Boot，只需20行左右的代码即可生成一个基本的Spring Web应用，并且内置了tomcat，构建的fat Jar包通过java -jar就可以直接运行；
    ●  如下特性使得Spring Boot非常契合微服务念，可以结合Spring Boot与Spring Cloud和Docker技术来构建微服务并部署到云端：①、 一个可执行jar即为一个独立服务；②、很容易加载到容器，每个服务可以在自己的容器（例如docker）中运行；③、通过一个脚本就可以实现配置与部署，很适合云端部署，并且自动扩展也更容易；
【2】SpringBoot 有哪些特性：  
    1）无需手动管理依赖 jar包的版本：
      ●   spring-boot-starter-amqp通过spring-rabbit来支持AMQP协议（Advanced Message Queuing Protocol）；
      ●   spring-boot-starter-ws支持Spring Web Services；
      ●   spring-boot-starter-redis支持Redis键值存储数据库，包括spring-redis；
      ●   spring-boot-starter-test  支持常规的测试依赖，包括JUnit、Hamcrest、Mockito以及spring-test模块；
    2）独立运行的Spring项目：Spring Boot默认将应用打包成一个可执行的jar包文件，构建成功后使用java -jar命令即可运行应用。或者在应用项目的主程序中运行main函数即可，不需要依赖tomcat、jetty等外部的应用服务器。其中内置的servlet Container。此外，你仍然可以部署Spring Boot项目到任何兼容Servlet3.0+的容器；
【3】SpringBoot 总结：
    ●  缺少注册、发现等外围方案；
    ●  缺少外围监控集成方案；
    ●  缺少外围安全管理方案；
    ●  缺少 REST 落地的 URI 规划方案；

所以 SpringBoot 只是一个入门级的微框架

 ----架构师资料，关注公众号获取----