概述
- 了解微服务组件
- 运行微服务
通过流行的SpringCloud框架，微服务组件调用，微服务业务流程，kubernetes自动编排容器，部署架构实施与发布流程规范，服务网格，全面解读微服务架构设计。
目标
通过微服务组件，组件间调用原理与业务流程分析来了解微服务工作原理
贴近企业实际使用环境
实践与理论结合，快速撞我微服务架构设计与容器编排技术，能独立实施部署CI/CD环境
1. 微服务架构介绍与框架
1.1 微服务架构介绍
微服务架构是一种软件架构模式，将单一应用程序划分成一个个小的服务，服务之间互相调用，或者通过网关调用运行。每个服务运行在其独立的系统进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的Restful API）。每个服务都围绕这具体业务进行构建，并且能够被独立的部署到各个软件环境中。
概念：把一个大型的单个应用程序和服务拆分成数个甚至数十个支持业务的小服务，每个小的服务可以独立运行与部署。
1.2 为什么需要微服务
在传统型应用系统中，虽然区分业务模块与基础模块，但是不能做到每个服务独立运行与部署，那么在后台将是一个统一的服务体对外提供服务。在用户访问前端使用负载均衡进行4-7的负载。后台采用缓存，数据库，共享存储进行数据的共享。
在业务代码更新过程中，不可避免的会影响到其他业务的系统。而在上线之前，一般都会经历测试阶段，但是在业务系统庞大之后，不论每次软件版本功能的更新大与小，测试都是无法全面测试的。有时候甚至是在当时上线没有发现问题，可能会在下次发布或者是在其他的操作过程中，才发现问题，这样处理问题的故障定位就会异常的复杂，不能快速准确的定位问题。基于此背景，微服务概念应运而生，其发展经历了几个阶段：
- 传统软件架构模式
- SOA（service-oriented architecture，面向服务架构）模式
- 微服务模式
单一服务 （PHP,Tomcat）
- 单一服务，对外提供服务，甚至没有前后端分离
- 部署简单，服务器数量要求少
SOA （dubbo，zeroICE）
- 前后端分离，后台服务有管理中心统一注册管理，业务模块分离。
- 服务拆分之后，服务治理相对较弱，主要基于SDK调用与docker融合性不是特别强
微服务 （SpringCloud）
- 前后端分离，后台服务有管理中心统一注册管理，业务模块分离，更细致的业务拆分。
- 服务管理与服务治理有相应的成熟的框架，基于HTTP方式调用数据，与docker紧密结合。
1.3 传统应用架构，SOA和微服务的区别
1.3.1 传统应用架构
传统的企业级应用是单机或双机集群应用（php，tomcat），一般采用分层结构，如应用层（代码逻辑）/数据层（数据库），这主要是水平切分的思想。每个应用之间的耦合性比较高。
1.3.2 SOA的服务模式
SOA（面向服务的软件架构，Service Oriented Architecture），是一种软件设计模式，主要应用于不同应用组件间通过某种自定义协议来互相通信，客户端调用需要集成其SDK。
正是因为传统的软件架构模式，带来的系统每次更新与部署，都有可能会导致系统出现异常，那么将服务拆分为独立部署的单个应用，势在必行，并且业务逻辑之间互相不影响，不需要依赖其他业务模块运行，有独立的进程和端口。
1.3.3 SOA的调用方式
在SOA软件架构模式中，通常是采用SDK的调用方式，如果有客户端需要http方式调用，那么可以在SOA软件之前添加http请求代理，这层代理通常由php完成。
SDK调用方式并发比http方式调用高，其主要原因是它可以采用自定义的私有协议进行通信，在自定义的协议中，对数据的传输可以做一定的优化处理(数据压缩)。
但是SDK调用也存在一定的弊端，比如客户端调试困难，客户端更新SDK版本需要考虑到兼容性，其中典型的SOA架构有：zeroICE，Dubbo。
1.4 微服务的优点与缺点
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上这种架构类型是移动互联网现在最流行的软件开发框架。在微服务架构中，集中式业务服务管理几乎不存在，微服务使用轻量级HTTP接口进行通信。
在SOA架构发展之后，相比微服务能够基于框架快速的开发应用程序，甚至都不需要专用的启动web服务（性能瓶颈）来启动微服务，而自身的软件框架已经携带。
在各个软件运行环境中（测试，开发，生产），运维与开发人员经常需要修改不同环境的配置文件，在操作中因为失误导致服务异常的情况经常发生，之前的SOA架构如果需要实现配置中心功能，那么需要借助第三方的配置中心（有些SOA框架自带，但是功能较弱），但是这一切相对于微服务而言，实现起来比较简单，包括一系列的服务治理方案（服务管理手段），在框架中早已经集成，大大降低了开发人员的工作负载，使得软件开发人员只需要专注于业务逻辑开发，而不需要关心软件框架的内部实现。
在后期的容器云中，客户端使用http协议的方式，使得微服务框架能够非常方便的融入docker并且通过docker的ingress功能实现对服务的弹性负载均衡。
1.5 微服务的优点与缺点
1.5.1 微服务的优点
- 优势复杂度可控（复杂度降低）
在将业务应用拆分以后，是的原本复杂的应用，变得简单。每一个微服务只有单一的某一项功能，并通过定义良好的接口调用模式，使客户端调用更加简单。由于“体积小，复杂度低”，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。 - 独立部署（web）
由于微服务具备独立的运行进程，所以每个微服务可以独立部署。降低了应用部署的复杂度。 - 技术选型灵活（SpringCloud）
微服务架构下，业务逻辑是去中心化。每个团队可以根据自身业务的需求和行业发展的现状，自由选择最适合的技术栈。由于微服务相对简单，故需要对技术栈进行升级时所面临的风险较低，甚至完全重构业务也是可行的。 - 容错（熔断）
当某一组件发生故障时，在单一进程管理的传统框架模式下，故障很可能在进程内扩散，行程应用全局性的不可用。
在微服务架构下，故障会被隔离在单个服务中。若代码质量高，其他服务可通过重启，销毁等机制实现应用层面的容错。 - 扩展
单应用架构也可以实现横向扩展，也就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。
1.5.2 微服务的缺点
- 代码重复
由于每个服务能够独立运行，有时需要向不同的服务添加一些相同的代码，就会导致代码重复，并且也增加了开发人员的工作量。 - 运维复杂
在采用微服务架构时，系统由多个独立运行的微服务构成，需要一个设计梁浩的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才能够更好的运维业务系统。 - 影响性能
微服务间通过http等形式进行交互调用，通信的时延会收到较大的影响。
1.6 微服务应用场景
在一个完整的软件工程项目中，一般分为以下几个层次
- 基础服务层
比如：用户登录模块，用户权限校验，用户个人信息，搜索引擎，邮件中心 - 业务服务层
比如：数据中心，新闻资讯，个人博客，视频通信，至少是服务化的。这层就是所有网站应用的核心。除此之外就是第三方平台的API对接。 - 工具类封装
比如：数据库访问驱动，搜索引擎，redis，memcache
*服务治理
比如：服务监控，服务降级，限流
业务逻辑架构图
说明：
基础集群不建议使用docker，需要保持基础集群的稳定性。如果使用请使用SS控制器（每个pod都有唯一的标示ID）
基础服务是为业务服务提供服务的
1.7 微服务与docker的关系
docker是一个开源应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的擦偶作系统支持的容器上，也可以使用虚拟化系统运行容器，容器是完全使用系统隔离机制，相互之间不会有任何接口依赖。
docker只要在支持docker的操作系统上运行，就可以运行微服务。类似JAVA的跨平台性，只需要JVM虚拟机就可以运行JAVA代码。
docker作为容器工具可以把软件拆分成若干个标准化容器（业务逻辑容器，数据库容器，存储容器，队列容器），然后容器间相互通信，从而形成微服务。
1.8 微服务常见实现框架
1.8.1 Dubbo
Dubbo是一款高性能，轻量级的开源JAVA RPC框架，它提供三大核心能力：面向接口的远程方法调用，只能容错和负载均衡，服务的自动注册和发现。
1.8.2 zeroC ICE
Ice是RPC通信领域里最稳定，强大，高性能，跨平台，多语言支持的老牌开源中间件，特别适合于当前互联网领域中一个平台存在多种开发语言编程，以及网站和app应用并存的复杂大型项目。
支持客户端API的语言有C++,.NET,Java,Python，Object-C,Ruby,JavaScript等。在服务器可以使用C，.NET，Java，Python等来开发。
1.8.3 Spring Boot介绍
Spring Boot可以建立独立的Spring应用程序
内嵌了如Tomcat，Jetty和Undertow这样的web容器，可以直接运行而不需要部署。
1.8.4 Spring Cloud介绍
基于Spring Boot实现的服务治理工具集。
利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册，配置中心，消息总线，负载均衡，断路器，数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud家族
1.9 HTTP状态码
| 状态码 | 意义 | 解释 | 通用 |
|---|---|---|---|
| 101 | Switching Protocols | 请求者已要求服务器切换协议，服务器已确认并准备切换 | WebSocket |
| 200 | OK | （成功）服务器已成功处理了请求 | web/api |
| 201 | Created | （已创建）请求成功并且服务器创建了新的资源 | api |
| 202 | Accepted | （已接受）服务器已接受请求，但尚未处理 | api |
| 204 | No Connect | （无内容）服务器成功处理了请求，但没有返回任何内容 | api |
| 301 | Moved Permanently | （永久移动）请求的网页已永久移动到新位置，服务器返回此响应（对GET或HEAD请求的响应）时，会自动将请求者转到新位置 | web |
| 302 | Move Temporarily | （临时移动）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求 | web |
| 307 | Temporary Redirect | （临时重定向）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求 | web |
| 400 | Bad Request | （错误请求）服务器不理解请求的语法 | web/api |
| 401 | Unauthorized | （未授权）请求要求身份验证，对于需要登录的网页，服务器可能返回此响应 | web/api |
| 403 | Forbidden | （禁止）服务器拒绝请求 | web |
| 404 | Not Found | （未找到）服务器找不到请求的网页 | web |
| 500 | Internal Server Error | （服务器内部错误）服务器遇到错误，无法完成请求 | web |
| 502 | Bad Gateway | （错误网关）服务器作为网关或者代理，从上游服务器收到无效响应 | web |
| 503 | Service Unavailable | （服务不可用）服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态 | web |
1.10 微服务调用基础
1.10.1 什么是API
API是由一组定义和协议组合而成，可以用于构建和集成应用软件，API是应用编程接口的缩写。
客户端在访问服务端某个业务时，需要知道服务端的访问地址与需要发送的数据类型和结构，从而从服务端获取到需要的数据。
1.10.2 RPC与Rest
RPC（Remote Procedure Call Protocol）:我们常用的远程调用方法，就想调用本地方法一样调用远程方法，通信协议大多采用二进制方式。通常基于TCP实现（介于TCP与http之间的通信协议），常用的框架如：dubbo，netty，thrift，而实现rpc通信，需要客户端安装专门的支持服务端的SDK。
RPC调用方式：
客户端代码需要集成服务端SDK，然后创建对象，调用获取数据的方法，通信效率高，集成与更新不方便。
Rest：严格意义上说接口很规范，操作对象即为资源，对资源的四种操作（http操作）（post，get，put，delete），并且参数都放在URL上，但是不严格的说即Http+json，http+xml，常见的http api都可以成为Rest接口。实现Rest调用，只是需要http客户端即可。
Rest调用方法：
只需要简单的支持http客户端请求即可访问服务端api，使用方便，无需更新，效率相对于rpc而言较低。
1.11 小结
为什么需要微服务
微服务优点与缺点
常用的框架有哪些
微服务调用基础