什么是微服务，微服务的思考和认知

近期看了杨波老师讲的《微服务》课程，深有感触，准备做下记录和学习笔记，希望能寻找到更多的一些方法论和思想进行微服务架构上的指引。

 

 

谈到微服务，有必要谈到两个人，这两个人对微服务架构的定义产生非常深远的影响，一个是马丁福勒，一个是netflix架构总监Adrian Cockcroft，netflix公司对整个微服务架构推进起到决定性的推进作用。其中马丁福勒在一篇博文中说了几个微服务定义的核心点，这里把它罗列出来。

 

 

第一个人马丁福勒认为微服务架构是一种架构风格，此架构风格包含了上图的六个特点

一组小的服务

原来的单块服务都是业务能力大而全的打包在一个单块中，微服务主张把这些单块服务进行拆分，形成一个个小的独立的服务。这里有个最大的特点是“小”，那么纠结要小到什么程度才为之小，很多同学都会纠结这个小的点，因为这个小并没有特别和明确的规定，所以这也就引申出了现在很多DDD领域驱动设计来指引微服务的拆分，但基本上一个微服务能让一个开发人员能够独立的理解，基本上就称为一个微服务，具体有多少行代码并不是很关键。

独立的进程

微服务是运行在独立的进程当中，例如java程序部署在tomcat，也可以部署在容器docker中，容易本身也是一种进程，所以微服务可以以进程的方式去扩展。

轻量级的通讯

微服务主张使用轻量级去构建通讯机制，例如http，固定消息格式和减少消息格式，服务之间不耦合，让通讯尽量轻量。

基于业务能力

微服务是基于业务能力进行构建，例如有用户服务，登陆服务，商品服务，基于这些业务能力去构建这些微服务。

独立部署

微服务被拆分开后，每个团队独立维护自己的微服务，开发，迭代自己的微服务，是可以独立的去部署，团队之间是不需要特别的去协调，这些对业务开发维护可以做到更加的敏捷，轻量，快速。

无集中式管理

原来单体服务是需要整个技术团队是需要独立的架构团队去管理，统一架构，统一技术栈，统一存储，微服务就不太一样，微服务主张每个团队根据自己的技术需要，选择自己最熟悉，最高效解决问题的技术栈，甚至选择不同存储方式。

说到第二个人netflix架构总监 Adrian Cockcroft，他给微服务下了一个定义 ： "Loosely Coupled service oriented architecture with bounded context"

• 首先第一点：服务之间应该是松散耦合，不能对周边有强依赖，如果一个团队的开发对周边有强依赖性，则不能认为松散耦合
• 其实第二点：服务面向的架构，微服务还是在本质上无法脱离SOA的理念，本身来说还是一种SOA，只是更加细化落地。
• 第三点：有界上下文，每个团队可以维护自己的数据源，不是集中式的数据源，每个团队可以自己独立去演化自己的数据源，对业务的支持会更加敏捷

思考点：

微服务可以独立部署，独立部署给业务带来什么的好处？ 微服务是基于有界上下文，每个团队是可以拥有自己独立的数据源，但在分布式系统中每个团队拥有了独立的数据源会带什么挑战？