所以，到底什么是微服务？

1、微服务是一种软件架构，是聚焦在单一的职责和业务功能，具有独立的进程，能够单独运行的服务，并且与外部服务是通过HTTP进行交互通信的服务。

2、微服务比较常见的特性是，具有单一职责，具有松耦合，具有高内聚等特点；

3、所理解的微服务特性，对比起单体应用来说，具有以下特点：

（1）屏蔽技术限制：

如何理解技术限制，就是假设你用的微服务是采用了java语言，如果需要验证新的语言特性，比方采用go语言，那单体应用是没法去单独验证的，只有不同的微服务才能对某个微服务进行语言的替换和验证；

（2）快速的部署：

可以采用Jenkins持续集成到kubernetes集群，进行快速的集成部署，并且区别与单体应用，单体应用需要整体进行集成部署，但是对于微服务，可以选择性的部署对应的功能模块，由于微服务体量相对更小，部署的速度会更加的具有效率；

（3）故障隔离：

所谓的故障隔离，是指比方支付宝中，你在进行订单支付的操作，如果此时账单查询的服务坏了，并不会影响你正常进行订单支付的操作；

（4）容易掌控：

对于开发者而言，每个微服务相对独立，并且专注在某个业务功能，掌控起来自然比大的单体应用要更加的简单；

（5）可伸缩性；

这个特性可能是最重要的，还是比方一个电商管理系统，假设订单查询服务的访问量逐渐增多，服务器原本的配置已经无法抗住请求量，那就可以增加查询微服务的服务实例，对请求进行分发，降低服务器压力，这种伸缩方式具有最实际的效用，并且能最大化提升应用的性能；

4、微服务怎么设计：

既然功能描述的比较好，那如何来进行微服务的设计呢？

目前来说，业界一般采用领域驱动设计进行微服务的设计，所谓的领域驱动设计，即通过拉齐业务语言，识别出该应用具体分为哪些领域，比如可以分为核心业务领域（核心域），支撑性领域（支撑域），通用的业务领域（通用域）等等，比如说物流管理系统，分为物流域（核心域），客服域（通用域），销售域、仓储域（支撑域）

先通过业务角度，识别出每个领域的边界和职责，上下文的联系关系，领域驱动设计的核心述求就是：松耦合，高内聚；将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。

简单来说，领域驱动设计就是一套设计方式，通过拉齐业务和技术语言，通过战略侧的事件风暴，合理划分出对应的领域和界限上下文，进而到战术侧，识别出对应的领域模型，从而构建出代码的层次结构，后续可以出一文专门讲解下领域驱动设计内容；

5、对我们来说怎么用，客观辩证看待微服务架构：

那对于我们来说，应该怎么用呢，其实这要仔细探讨下，是否每个项目都是需要以微服务方式来做，固然微服务的特性是很好，但是非所有应用都能适用；

（1）微服务所需的基础设施多：

比如一个简单的单体应用，部署在云上，则所需资源是：

①负载均衡器

②一个服务实例

③一个关系型（或者非关系型）数据库

④用于日志检索的kibana

如果换做是微服务：

①一个kubernetes集群

②一个应用的负载均衡

③应用和集群的多个实例

④一个或者多个数据库，具体看服务的策略（是否一个服务对应一个数据库）

⑤一个用于服务间通讯的消息中间件，kafka，rocketMQ等

⑥用于持续集成的jenkins

⑦用于日志的kibana

⑧用于监控的Prommetheus

⑨还有用于跟踪的Zipkin

如果只是从高级的层面来看微服务架构，自然是优势的特性会很多，但是如果落到具体实施层面，所需考虑的运维成本会比想象得更高，比如这些部署的中间件，如果集群出现问题，如果消息中间件宕机了，如果这些服务间的消息没有及时消费，等等，那这些运维成本也会很高；

（2）微服务所需配套的文化：

如果业务部门，并不关心底层的系统实现，那么会对实际实施影响很大；

比如说，现在有个很复杂的微服务应用，它牵涉的服务有十来个，那么现在产品负责人，或者说产品经理，需要实现一个小需求，原本只是一周的工作量，但是由于服务之间的互相调用，功能上的依赖，实现这个需求可能要比单体应用多出几倍的工作量。往往这个时候，就要看是否产品负责人，或者业务部门，能够认可这个底层带来的工作量变化。

（3）无法很好的划分微服务：

虽然现在有DDD（领域驱动设计）方法论进行引导，但是对于大部分项目而言，都需要有资深的架构师，并且具有微服务实战经验的，才能真正的落地出比较好的实践，不然对于新手或者接触不久的人而言，现在对微服务的划分，和业务领域的识别，是没法达到真正的高内聚，低耦合的。

这可能造成的后果是，无法将微服务拆分到合适的大小，并且有明确的边界，在后期扩展，迭代过程中，能够一直保持服务的独立性，非强依赖性。

而且微服务如果拆分太小，假设一个应用，拆了50+的微服务，那对应的部署速度不是更快了，而是更慢了，毕竟在jenkins部署时候，或者构建服务时候，都可能出现问题，服务越多，问题就越多，部署成本就越高。

综合来看，是否需要采用微服务架构，还是要看具体的应用复杂度，结合已有的资源，和运维成本，是否 能够覆盖，这样才能更全面判断是否要采用。