本文首发于本博客 猫叔的博客，转载请申明出处
公众号：Java猫说
现架构设计（码农）兼创业技术顾问，不羁平庸，热爱开源，杂谈程序人生与不定期干货。
视频教程地址
第一章 从传统单体架构走向微服务
Hello，大家好，我是猫叔MySelf，本课程将带领大家入门微服务。
各位年轻又帅气的靓仔们！
- 新入职公司，接手公司项目，你所看到的是不是就是一座大山
- 你们接触的项目是不是庞大的代码块、并关系错综复杂（一大堆的目录与包）
- 是不是接手后交付周期也很长（入门也是几个通宵）
- 有没有觉得该项目的扩展能力与弹性受限
- 同时，对于大家这样热爱新技术的同学，有时一用上新技术与工具框架就各种BUG
- 而且一个微不足道的小问题，可以导致整个应用挂掉（高层还总是唠叨我们）
也是辛苦大家那段时间每夜每夜的加班工作了！
在听微服务之前，因为学员层次不一，希望大家有了解到至少一个单体架构的web项目开发经验或大致流程，这样学起来更轻松哦！
聪明的老外总是能先于我们发现新的高效的开发模式，近几年前一个老头就提出了我们将要学习的“微服务”：微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
大叔的图片
这个看起来有点复杂，我就不念了，像教科书一样的文案，有兴趣的同学可以上网深入了解。
我们整理一下，并优先入门一些重点。
- 其目的是有效的拆分应用，实现敏捷开发和部署
- 只做一件事，并把它做好
对于我们这种要求简单的，工作的时候一般都只想做一件事就好了，不 要让我顾及太多。
- 单一（隔离）、独立指责
我们可以尽情的在自己负责的项目上“玩耍”啦！对于其他服务层的对接仅需要按照各个应用通信接口文档去走即可！
- 通信（同异步）
我们总是要和人交流的，对于我们自己独自负责的服务也是需要去交朋友的，因此它需要与其他各个服务进行通信，这里的通信可能是同步的、异步的。 对于每个引用都有他们自己的数据，微服务的采纳有助于我们可以针对部分火爆业务采用不同的数据库类型或者分库读取，而不再需要在同一项目整合多个数据库操作。
- 数据独立
我们可以发挥不同语言的优势，比如python、nodejs、php….这对技术专项不同的开发团队来说，配合起来将更加容易与得心应手。
- 技术栈灵活（数据流、存储、业务）
- 独立部署、团队组织架构有效调整
第二章 单体架构电商Demo讲解
一个普通的电商项目：
- 用户服务：注册
- 商品服务：查询商品
- 订单服务：下单、查看订单
数据库表：
- 用户表：用户id、用户名、用户密码、创建时间
- 商品表：商品id、商品名、商品详情、商品价格、
- 库存表：商品id、库存数
- 订单表：订单id、用户名、商品id、订单价格、商品总数、创建时间
大致的模拟环境：
用户下单与查询订单列表，同时还具备管理人员查询库存
接口列表：
- 地址：
http://localhost:8080/sells/order/orderPOST -
参数
id 》 用户id goodsId 》 商品id num 》 商品数量
- 例子
{ "code": 200, "msg": "成功", "data": "MS04780334" } - 地址：
localhost:8762/order/order?id=1GET -
参数
id 》 用户id
- 例子
{ "code": 200, "msg": "成功", "data": [ { "orderId": "MS04475904", "goodsId": "MS000001", "name": "猫叔", "orderPrice": 1598, "orderNum": 2, "createTime": "2018-12-13T05:59:24.000+0000" }, { "orderId": "MS04663799", "goodsId": "MS000002", "name": "猫叔", "orderPrice": 2999, "orderNum": 1, "createTime": "2018-12-12T16:04:18.000+0000" }, { "orderId": "MS04780334", "goodsId": "MS000001", "name": "猫叔", "orderPrice": 1598, "orderNum": 2, "createTime": "2018-12-13T08:10:29.000+0000" } ] } - 地址：
localhost:8763/goods/goods?id=1&goodsId=MS000002GET -
参数
id 》 管理员id goodsId 》 商品id
- 例子
{ "code": 200, "msg": "成功", "data": { "inventoryId": "IN4567825", "goodsId": "MS000002", "inventoryNum": 13 } }
微服务架构拆分
当前只有三个服务，一个用户服务、一个订单服务、一个库存服务
假设我们的生意狂飙上涨，投放了分销环节、线上广告啥的，这个时候的订单量非常高。那么我们就可以使用微服务的思想，讲订单服务抽离出来。
那么我们将使用SpringCloud来完成这一操作与编码。
在基于单体架构的情况下，我们将进行手把手的演进，希望同学们可以一起来撸一把。
首先是Eureka注册中心，我们需要向某人说明这里是什么，
并将单体服务拆分为两个，order-client服务 还有 其余的服务。
那么我们就再新建两个对应的Eureka Client的服务并注册到注册中心
同时两个服务之间的通讯也需要采用SpringCloud的操作。
第三章 SpringCloud入门
说到SpringCloud，我们还需要说一下它基于的更厉害的框架，它就是Netflix。Netflix的多个开源组件一起正好可以提供完整的分布式微服务基础架构环境，而SpringCloud就是对Netflix的多个开源组件进一步封装而成的。
同时，它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，比如我们今天将学到的服务发现注册（Eureka）、调用框架（声明式服务客户端Fegin）等等。
Spring Cloud将目前各个比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，因为我们仅仅配置一下、写几句代码就可以实现一个想要的简单的微服务。
第四章 Eureka实操与微服务架构搭建
Spring Cloud Eureka
- 1、Eureka是一个基于REST的服务
- 2、基于Netflix Eureka做了二次封装
- 3、核心组件为：
- Eureka Server 注册中心（服务端）
- Eureka Client 服务注册（客户端）
第五章 服务拆分与应用间通信
Spring Cloud 服务间的一种RestFul调用方式
1、Feign
- 声明式REST客户端
- 接口 + 注解（开启、指定服务名）
- 本质依旧是一个HTTP客户端
第六章 关于微服务的不解与深入探讨
我想极具好奇心的同学们一定不满足这么一点的概况，的确，微服务还有更多的知识点需要大家去掌握与了解。
- 负载均衡
- 安全机制
- 配置中心
- 链路追踪
- 容器搭配
说了那么多，微服务的缺点是什么呀！？我总是希望唱反调的同学
毒液中的片段，世界掌握在我们手中
没错，任何思想都有其适用性与自身环境，微服务也不例外。
在介绍了微服务原理后，大家会提出什么问提呢？
我做学生的时候就提出了几个小问题。
-
微服务架构的取舍？
需要避免为了“微服务”而“微服务”。
对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。
-
微服务的不足又是哪些？
微服务的复杂度 分布式事务（CAP理论，AP系统） 服务的划分 服务的部署
-
各个服务组件的版本与部署乃至升级？
一套完善的开发管理规范，包括开发设计规范、分支管理规范、持续集成规范，再利用Docker容器的天然的特性：“版本控制、可移植性、隔离性”就可以实现组件的版本管理。实质上基于在支持DevOps完整流程的容器云平台，即可实现整个开发过程及交付中的持续集成、快速部署、灰度发布及无缝升级。
最后希望大家都能在未来深入了解并使用微服务。
