关于微服务的相关内容

一、什么是微服务

  提到微服务，不得不提下Martin Flowler大神，这个词就源自于它的一篇Microservices的文章，原文地址如下：https://martinfowler.com/articles/microservices.html  
  微服务应该算是软件系统架构上面的一种设计分格，将一个独立的系统拆分成多个小型服务，各自在独立的进程中运行，服务之间通过基于http的 Restful API（RPC－TCP socket）进行通信协作。每一个小型服务围绕着某些功能进行构建，各自管理自己的体系，维护着自身的数据存储，业务开发，自动化测试以及独立运营，同时因为是基于http通信，各个服务都可以进行跨语言开发。

二、单体系统存在的现状

 1、单体系统业务越来越复杂，一般互联网项目开始都是单体设计，数据库访问、服务端处理、业务逻辑都放在一起进行处理，业务发展初期表简单，但是随着业务逻辑越来越复杂，耦合行更高，开发上手难度就越来越大。
 2、一个系统一大堆接口模块支持，现在移动互联网，服务端需要对客户端提供接口支持，服务端对前端需要更多的接口支持，接口方面管理也就越来越庞大。系统愈加臃肿
 3、单体系统的修改影响其它功能
 单体系统中的功能都是交叉的，软件开发者很难保持原有好的模块架构，使得一个模块的变更很难不会影响到其它的模块，而且在扩展方面也只能进行整体的扩展，而不能根据进行部分的扩展。
4、系统的容量难以监控和评估
单体应用，各模块运行在一个实例中，共享着系统资源，对于资源交叉使用很难评估和监控系统情况。

三、微服务的问题

  以服务构建应用。这些服务还可以被独立布署、独立扩展，每个服务也都提供了清晰的模块边界，甚至不同的服务都可以使用不同的编程语言来实现，也可以由不同的团队进行管理。这就带来很大的开发便利，当然也存在很多问题：
  1、运维新挑战，当拆分成许多微服务，分开部署后，维护的进程数量会大大增加维护的难度会增大，这样的会需要多考虑自动化运维。
  2、接口一致性问题需要考虑到，因为微服务太多，接口修改之后相应的服务调用方也要进行相应的修改，以保证接口正常的调用。
  3、分布式的复杂性，当微服务拆分，业务、存储各成体系，会设计到很多分库分表的问题，各个微服务通过网络进行通信，因此会存在网络延时，分布式事务，异步消息等问题需要去处理。

四、微服务的特性

1、服务的组件化，组件的定义是：一个组件是软件中的一个部分，可以独立的替换和升级。微服务也会使用组件库，将一个软件组件化的主要方式就是将其分解成服务，我们定义的库是可以连接到程序并使用内存函数的的组件库，服务是进程外的组件，如Web请求服务或者远程调用来相互通信的组件。
2、去中心化治理，微服务架构通过轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不在敏感，多种技术开发语言可以糅合在一起使用。
3、基础设施自动化，微服务化后自动部署自动测试需要运用起来以支持持续化的交互。
4、容错设计，微服务拆分后，很可能存在有的服务正常，有服务出现异常的情况，针对这种情况通常需要能够快速检测异常快速恢复，同时当调用服务出现异常需要设计降级等处理。
5、去中心化的管理数据，微服务拆分后，我们可以根据业务需求可以把原有数据库存储的数据根据需要采用不同的存储技术，比如日志记录存储到Mongodb、HDFS、热点数据存储到Redis等

以上就是微服务的相关内容，现在微服务概念出现后，许多公司都会觉得微服务必须要上，其实没必要早先的业务需求没有必要一下子就上微服务，单体应用完全满足业务需求，微服务化是一个演进式的设计，当你的用户量、并发量、数据量越来越多，同时业务越来越复杂之后，才可以考虑慢慢的进行微服务化。