微服务是一种细粒度(Fine-Grain)的SOA.与其说微服务是一种技术，不如将其定义为一种架构，而架构则是“技”的实现与“术”的策略相辅相成。
具有编码灵活、兼容性好、性能优秀、多种页面结构化

前言

最近这几年微服务比较火，很多技术公司对招聘java工程师，都是以有微服务架构开发经验的求职者优先，仿佛不谈点微服务相关的技术，都显得不是那么主流了。

一：什么是微服务

1、 微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”(http://martinfowler.com/articles/microservices.html)。

2、微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

3、如果要用比较通俗的解释，我觉得可以用如今手机行业的手机生产制作来形容，如今各个手机厂商每台手机几乎都是各大厂商技术的集合体，就比如一台小米手机，cpu可能来自高通，屏幕来自三星，摄像头来自索尼等等，手机每个部分都由不同厂商提供，强强联合，才能制作一台真正优秀的手机，而微服务就像这样，每个功能点单独完成，最后组成一个强大的项目。

二、为什么使用微服务

提到为什么使用微服务架构就应该先了解一下一体化架构。

1、什么是一体化架构？

答：一体化架构顾名思义，将应用各层打成一个包来部署。为了让代码正常工作，一体化应用的所有组件缺一不可，各部分高度依赖。比如我们常见的普通web项目，一般分为表现层，业务逻辑层，数据访问层，所有代码都放在一个代码库中，某一层的代码变化都影响整个项目的构建和部署。

2、为什么使用微服务架构

答：微服务架构其实就是一种架构风格，我们将整个项目划分为多个独立的小项目，也就是我们俗称的微服务，但是微服务的“’微”并没有明确的定义，可以理解为每个微服务都单独处理某个功能模块，可以独立开发、测试、部署、监控和扩展，甚至可以用不同的编程语言开发它们。它有利于我们平时项目的开发，解决了一体化架构项目难以扩展，开发周期长，故障级联等问题，这也是微服务近几年越来越流行的一个原因。

三、微服务有什么优缺点

1、优点：

独立开发部署服务

速度和敏捷性

更高的代码质量

获得围绕业务功能创建/组织的代码

改善故障隔离。一个服务宕机不会影响其他的服务

易于规模化开发，多个开发团队可以并行开发，每个团队负责一项服务

更容易扩展

可以使用不同的语言

2、缺点

测试工作更加困难

服务调用跨更多节点，分布式事务数据不一致性可能更大。

部署复杂，成本高

开发人员要处理分布式系统的复杂性，提高了开发的复杂性

服务调用跨网络，增加网络IO，降低性能。

3、这里也只是简单的列举了一些优缺点，如果要详细了解百度上很多，也很详细。

四、总结：

上面也只是比较简单说了一下微服务，其实无论哪种技术，哪种架构，有优点，也必有缺点，在开发中，这些问题我们其实天天都可以遇到，就比如常用的一些集合类型，效率高的，线程就不一定安全，线程安全的效率也不一定高。技术是死的，但是人是活的，我们只有面对不同情况，选择不同技术，最后才能真正的以最优的方案解决问题。

  简单举例：看军事新闻的同学应该都知道，一艘航空母舰作战能力虽然很强，但是弱点太明显，就是防御能力太差，单艘的航空母舰很少单独行动，通常航空母舰战斗群才是主要军事力量，你可以把单艘航母理解为的单体应用（防御差，机动性不好），把航母战斗群（调度复杂，维护费用高）理解为微服务。

  大部分的开发者经历和开发过单体应用，无论是传统的 Servlet + JSP，还是 SSM，还是现在的 SpringBoot，它们都是单体应用，那么长期陪伴我们的单体应用有什么弊端？我们是面临了什么问题，导致我们要抛弃单体应用转向微服务架构？个人总结主要问题如下：

  部署成本高（无论是修改1行代码，还是10行代码，都要全量替换）

  改动影响大，风险高（不论代码改动多小，成本都相同）

  因为成本高，风险高，所以导致部署频率低（无法快速交付客户需求）

  微服务架构的特点：

  1、针对特定服务发布，影响小，风险小，成本低;

  2、频繁发布版本，快速交付需求;

  3、低成本扩容，弹性伸缩，适应云环境。

  选择微服务在解决了快速响应和弹性伸缩的问题同时，它又给我们带来了一些问题：

  1、分布式系统的复杂性；

  2、部署，测试和监控的成本问题；

  3、分布式事务和CAP的相关问题。

   微服务设计其实是很早就有的设计思想，因为随着虚拟化技术的崛起，微服务可以低成本的实现，所以也开始流行和兴起。微服务的内涵很深，其中就包括，自动化，去中心化，独立性等等，其中细节无法用一篇文章概述清楚，我们在做技术选型或者方案的时候，尽可能多去了解技术的本身和起源再结合我们业务的特点，进行更好的选择

浅谈传统架构与微服务架构:

　　传统架构是单一架构模式,就是将项目整体打包部署,比如java语言的项目会打成war包,部署在tomcat或者jetty应用服务器上,如果使用springboot还可以打成jar包

　　微服务架构是将整体项目分割成项目关联的独立服务,一个服务通常会实现一组独立的功能,包含自己的逻辑,各个微服务之间关联通过暴露api来实现,这些独立的微服务可以部署在不同的服务器,虚拟机或系统中

为何要使用微服务架构:

　　单一架构模式在项目初期的时候开发,测试,部署方便,但是随着项目逐步开发,项目工程会很大,最终互相之间会有繁琐的jar包

　　　　1.不再适用于敏捷开发,任何开发人员都不能完全理解,在修复漏洞和添加新功能时候变得复杂

　　　　2.项目模块越大,启动越慢,很小的改动也需要重新部署整个项目

　　　　3.任何模块的漏洞,都会降低系统的可靠性

　　　　4.如果想整体使用新的技术,新的框架,那是不可能的

　　如果采用微服务,解决了单一系统的复杂性,主要有以下优点

　　　　1.可采用敏捷开发模式,选择合适的技术

　　　　2.每一个微服务是独立部署的,可以快速迭代部署

　　　　3.一些需要负载均衡的服务可以使用ngix同一反向代理分发请求,这样不需要整个系统负载均衡了

微服务的缺点:

　　　　1.微服务作为分布式系统时候带来了复杂性,当应用是整体应用时,模块之间可以内部调用,但微服务是多个独一的应用,调用起来增加了一定的复杂性

　　　　2.多个数据库,事物的实现会头痛

　　　　3.测试微服务变得复杂,当一个服务依赖于另一个服务时候,测试时需要另一个服务的支持

　　　　4.整体系统只需要部署在一组相同的服务器上,而微服务需要更高的自动化形似