什么是微服务？它有哪些特点？

微服务是一种软件架构风格，他是以专注于单一职责与功能的小型功能模块为基础，利用模块化的方式组合成大型的复杂应用程序，各功能模块使用与语言无关的API相互通信 —-wikipedia

微服务架构将单体应用拆分为多个高内聚低耦合的小型服务，每个小服务运行在独立进程，由不同的团队进行开发和维护，服务间采用轻量级通信机制，独立自动部署，可以采用不同的技术进行开发和使用独立的存储空间

微服务的特点

每个微服务仅对单个业务负责，且为该业务的功能负责
每个微服务独立进行部署，不需要依赖其他微服务及相关资源，如数据库缓存等
服务可替代,每个微服务原则上都可以使用不同的语言、框架进行实现，且更换技术实现的微服务对整个业务系统不会造成影响
每个微服务拥有单独的数据存储
每个微服务由小团队进行维护，服务以业务来进行拆分后，每个微服务将有人数不多的团队对其进行维护

为什么要用微服务？

为什么要用微服务，实际上就是每一种架构它的实际的使用场景是怎样的，或者说微服务架构它是为了解决哪些问题而诞生的呢？要聊这个内容实际上就要从单体应用开始讲

什么是单体应用呢?

单体应用就是将应用的所有功能都打包成一个独立的单元，最终以一个WAR或jar存在。

那么单体应用有哪些优点和缺点呢？

单体应用的优点:

便于开发只需借助IDE的开发调试功能即可完成
易于测试通过单元测试或者浏览器即可测试
易于部署打包成单一jar包或者war包，执行jar即可部署

缺点:

复杂性高随着业务的迭代，项目中的代码会急剧增多，项目模块也会随之增加，模块间的关系变得更加复杂，整个项目变得非常复杂，在
可靠性差一体化应用某块业务发生改变后，就需要整体重新测试、部署、很容易某个业务模块牵一发而动全身导致整个应用不可用，微服务则很好的解决了这个问题，某个服务不可用仅仅是影响它自己这一个微服务
扩展性差一体化应用只能通过在负载均衡器后面放置多个整个应用实例的整体进行水平扩展，非常笨重，而微服务则则可以根据需要对某个微服务进行按需缩放或者扩展
部署或者启动时间变长
交付时间长微服务架构中假定我们有100个服务，如果有一个服务中的业务发生了变化，则只需要对这一个服务进行迭代，测试、上线，而不是部署整个应用

其实引入微服务就是为了解决单体应用中的这些缺点而产生的

微服务架构带来了哪些问题?

服务数量成倍增长维护难度加大

在引入微服务架构后，由单体应用拆分出来的按业务职责划分的服务不可避免的爆炸式增长，使用传统方式运维，无疑就是灾难，这就使得微服务的基石–持续集成在拆分服务之前是必须解决的问题

复杂性提高，学习成本提高

由于引入了新技术，开发人员不得不从头开始学起这些新的内容，尤其是像引入微服务后，这就不可避免的带来了分布式的问题，比如分布式事务、业务体量上来之后，当数据库成为瓶颈后，可能不得不涉及到数据库层面的一些优化，比如分库分表的问题、分库分表之后又带来一些问题、分库分表后唯一主键问题，还有可能涉及到数据迁移的问题和全局表问题，这一系列的问题都是在引入微服务这一体系之后带来的问题，对于这个问题来说，只能说微服务它本身解决了一些问题，它带来的问题，我们可以再找一些别的方式去做处理，我也相信微服务它本身带来的好处要比它带来的复杂性要好的多，所以说对于增加的员工的学习成本来说，微服务是一种趋势，只能说“拥抱变化”了~

请求链路长问题排查成本较高

引入微服务后，经常会发现，某个服务出现问题，有可能并不是它自身原因导致的，有可能是它的某个下游服务出了问题，当我们逐级排查的时候，调用链路特别长的情况下，找到最根上的出问题的那个节点才能找到真正出问题的节点在哪里，就好比如果生产环境出了问题，这就会导致我们排查问题可能非常的耗时，我们都知道，生产问题尽早排查，尽快排查出问题的根本原因，尽快地修复问题，我们的损失就会越小，所以这个时候就不得不引入”链路追踪”,链路追踪就是把我们涉及到的每一次请求调用了哪些服务，调用的顺序、调用的层级关系以及每次调用花费的时间搞清楚，把这些内容串起来从而通过调用链快速定位到底是哪里出了问题。

未完待续—