开发者学堂课程【微服务+全栈在线教育实战项目演练（SpringCloud Alibaba+SpringBoot）：技术点-微服务概念介绍】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/667/detail/11412
技术点-微服务概念介绍
什么是微服务
我们现在是用的就是微服务架构，看一下我们的项目会更好理解，我们可以看到一个副工程，guli-parent，有一个子模块 service，这里还有三个模块，service-edu，service-oss，service-vod，
这三个有一个特点，就是 service-edu 是使用的8001端口启动的，service-oss 是8002端口启动的，service-vod 是8003端口启动的，是三个独立的工程，有占用了不同的号，这种架构方式就是一种微服务架构方式。
所以我们可以看到，目前的项目是建了三个部分，就是三个服务，第一个是service-edu，第二个是 service-oss，第三个是 service-vod，这三个我们使用不同的端口进行启动，分别是8001，8002，8003，这是我们最直观的感受，包括我们再有这种服务，写一个模块，可以用8005，8006等，这种服务就叫微结构。
1、微服务的由来
微服务最早由 Martin Fowler 与 JamesLewis 于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTPAPI，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
每个服务运行在自己的进程中，我们可以理解为我们现在拥有 edu，oss，vod，我们可以列为三个服，当我们一启动，每个服就会占用一个进程，每个服都是独立运行的，彼此之间没有影响，这种方式叫微服务。
重点如下：
（1），微服务是架构风格，
（2），有多个服务，多个服务是独立运行，每个服务占用独立进程。
2，为什么需要微服务
在传统的I行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高到后面引入了 SOA 服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如: J2EE。
这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。
回顾一下，在早期做项目时，我们是怎么做的呢？
比如我们说 web 阶段，单独的项目，我们就是建一个 web 的工程，在里边儿写各个类，各个的代码，包括页面。这些是都放到一个工程中去的。这是我们之前做的方式。
一个项目里边要写所有的代码，这样写代码，它有一种方式，这就叫做单体架构方式。
把一个项目拆分成独立多个服务，多个服务是独立运行的，每个服务占用独立进程。
他们每个都是独立运行，占用独立的进程，互不产生影响，这就是他的一个特点。这么做的好处是什么呢？
它的功能更加明确每个里面只有自己的特有功能，edu中就是自己的课程，oss就是上传的。vod就是视频的。互相他们都是独立的。这就是他们的一大特点。而我们在最终的项目部署中，我们可以把我们的每个服务单独进行。
3、微服务与单体架构区别
(1)单体架构所有的模块全都合在一块，代码量大，维护困难。
微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
(2)单体架构所有的模块都共用一个数据库，存储方式比较单一。
微服务每个模块都可以使用不同的存储方式(比如有的用redis，有的用mysql等)，数据库也是单个模块对应自己的数据库。
因为我们是单体工程，用一个数据库，但是他的存储比较单一，假如我们现在使用微服务方式，我们就要看一个特点。
在我们的 edu 里面。可以看到我们配备了数据库的部分，而在 oss 里面。我们看到他也配置了数据库部分，那他的好处是什么呢？
如果我们在 edu 数据库中使用mysqi数据库里面的配置，在 oss 中使用数据库，在 vod 中使用数据库，他们可以在每个里面用不同的存储。虽然说单体应运中只能应用，不能存储。但是他的做法会更方便。这就是他的优点，因为每个应用都是独立的。
(3)单体架构所有的模块开发所使用的技术一样。
微服务每个模块都可以使用不同的开发技术，开发模式更灵活。
因为我们所有单体架构中都起到一个功能，这就要求我们的技术只能是一个技术，假如我们写在一个里边儿，我的技术都用 Java，而用微服务有什么好处呢？
如果我们在微服务使用中，一个模块可以用Java，另一个可以用prp，第三个可能用 c++，用不同技术实现不同的模块。因为他们是独立部署，独立运行的。而这些好处还有一个特点，就是外包。这个外包不是指人力资源外包，而是向外包，就是很多欧美国家喜欢向外包。这要怎么做呢？
把项目中不是特别核心的一些模块，外包到其他的国家。例如印度。印度这些是最发达的，然后印度来开发里边儿的另外一个模块，但这个模块是独立运行的，独立部署的。比如美国开发用 Java，印度可能用另外一种方式，让你的程序通过不同技术得到实现，开发模式比较灵活，这个就叫微服务。
4、微服务本质
(1)微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。
这种所请的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
(2)微服务的目的是有效的拆分应用，实现教捷开发和部署。
(3)微服务提但的理念团队间应该是
inter-operate,notinteqrateinter-operate 是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变明，跨系统的沟通成本也就能降低。
5、什么样的项目适合微服务
微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，
如:操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部器和运行，也就不适合做成微服务了。
我们的在线教程就是微服务，因为里边儿有多个独立的服务，都可以独立运行，就很适合微服务。但是有些项目就不太适合。不是说所有东西都要用微服务。什么样的项目不适合呢？
像上面我们提到的，比如说系统中的业务是非常底层的业务，假如说我们做一个操作系统内核，或者一个存储系统，因为这里边它的底层要紧密关联，那么这种项目就不适合使用微服务。而有一种普通的应用，比如说我们在线教育他就适合使用微服务。
6、微服务开发框架
目前微服务的开发框架，最常用的有以下四个:
Spring Cloud:http://projects.springio/spring-cloud(现在非常流行的微服务架构)
Dubbo:http://dubboio
Dropwizard:http://www.dropwizard.io(关注单个微服务的开发) Consul.etcd&etc(微服务的模块)
如果我们要做微服务，就要有一些开发框架。运用框架开发，就会变得比较简单。
而目前有很多这样的框架。上文给大家列了几个框架。目前比较常见的是前两个，第一个是最流行的，第二个是 dubbo，我们这一个阶段学的就是第一个 spring cloud，后面的将会专门有课件来讲述第二种。
这两种是比较常见的架构，而这两种在公司中也比较常用。Spring cloud 是最常用的，但第二个也有在用，因为他出现比较早，所以公司项目依然还会使用过去的。后两个就是我们不常用的。
