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部署时候，或者构建服务时候，都可能出现问题，服务越多，问题就越多，部署成本就越高。
综合来看，是否需要采用微服务架构，还是要看具体的应用复杂度，结合已有的资源，和运维成本，是否 能够覆盖，这样才能更全面判断是否要采用。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
