微服务，字面意思，很小的服务。至于小到什么程度就需要根据不同的业务场景进行具体拆分了。微服务对于一套系统来讲，说白了就是这个系统的不同的组成部分，由这些不同的组成部分，通过一系列的编排组合的方式来进行系统的逻辑调用。做到真正意义上的独立运行、解耦合、组件化、可复用、高可用等，最终达到高质量交付的结果。
专业解读，微服务被看做一种架构模式，这种架构模式将单一的程序划分成了一组微小的服务。每个服务之间相互调用、相互配合，最终实现用户的业务逻辑。并且这些服务每个都独立运行，并且提供对应的业务逻辑支持。服务与服务之间通过轻量级的通信方式来进行互通。每个服务可以根据自己需要完成的业务逻辑所支持的语言选择合适的语言，合适的编程实现方式来进行开发。
总结一下，微服务的核心特点就是：微小，每个服务只专注于一件事情、轻量级的部署方式、轻量级的通信机制、实现了松耦合、高可用等功能。
微服务的优势
微服务之所以能被大多数开发者喜爱，是因为它提供的一些天然的优势，下面就来看一下微服务都有哪些优势。
技术异构
技术异构，在微服务中每个服务都是相对独立的，每个服务都可以选择一个合适的方式来实现自己支持的业务逻辑。例如在对接底层硬件的时候，可能C语言更加合适，面向用户侧的话可能Java语言或者是Python语言更合适。这样的话每种语言的优势都可以被发挥出来。
同时，在使用新的技术方案的时候，微服务也是提供了很好的尝试的空间。对于单体应用来说，如果想去在某个业务逻辑中使用新技术，就会影响到其他的业务逻辑，这样就会导致我们在尝试新技术的时候，只能是整体替换。导致技术迭代进行不了。但是在微服务中，可以完全将其中的一个服务替换成新的技术实现方式，而不影响其他业务。
弹性扩展
弹性，主要是来衡量一个系统是否能够保证核心业务的正常使用。在单体应用系统中，系统一个部分出现问题，就会导致核心业务也受到很大的影响。并且当核心业务流量增加的时候也没有办法对核心业务进行扩展。但是在微服务中，如果出现流量激增的情况，系统可以保证核心业务的正常工作，并且可以更具流量来进行一个弹性资源伸缩扩展。
部署简单
在单体应用中，如果因为一个业务逻辑调整优化了一行代码，就需要将整个应用重新进行部署。这种方式的危险性是非常高的。所以这个问题在微服务架构中则不存在，每个服务都是独立部署，影响的也只是对应的服务，并不会影响整个系统的业务逻辑。
结构匹配高
我们都知道，团队越大，问题越多，越难管理，代码也是一样的。当一个业务越做越大的时候，代码也会越来越多。在微服务架构中，采用了架构与组织结构相匹配的原则，避免出现业务交叉形成过大的代码库结构。从而实现了小团队的高效协同的生产力结构。每个服务对应一个开发团队。避免因为业务交叉而导致的责任不明确问题。
可组合
在微服务架构中，我们对服务进行了拆分解耦合，并且每个服务对外提供了大量的接口，当需要有一个新的业务流程需要进行组合的时候，就可以通过接口的调用形成一个组合业务结构。
微服务面临挑战
上面提到微服务有很多优势，但是微服务有优势就会有劣势。下面我们就来看一下微服务都存在哪些挑战。
复杂性升高
前面提到微服务是将业务系统进行了服务拆分，所以微服务要实现分布式要比单体架构实现分布式要困难。从高可用的角度上来讲，要将微服务进行多服务部署，并且服务之间的通信都是采用网络传输，所以在服务调用的过程中可能会受到影响。同时受到影响的就是数据一致性。
运维成本升高
相比于单体架构，微服务运维的复杂度是提升的，由于对单体应用进行了微服务拆分，并且每个服务都是独立部署，也就意味着原来只需要部署一个包的，现在需要部署十几个包。原来适用于单体应用的监控，配置，部署等方式都需要进行微服务的改造。对于部署来说，一天要有很多的服务修改部署上线，这些服务如果用人工的方式一个包一个包的去换，是行不通的。这就需要一些自动化的手段来实现。如何提升部署效率就成了微服务架构下需要面对的挑战。
DevOps与组织结构的变化
在传统的开发中，团队可以按照技能不同进行划分，例如开发人员、测试人员、产品、运维等等。但是在微服务架构实施的过程中，除了上面这些人，还出现了一个DevOps的角色，它是开发与运维的结合。
什么意思呢？微服务架构不仅仅带给团队一种架构模式，更带给团队一种组织模式，DevOps意味着开发与运维角色会发生互换，开发人员将承担起整个项目的全部生命周期，包括后续的运维，传统的运维则是更加倾向于一种顾问的角色。这就要求整个团队具有更加健全的团队能力。
链路测试
由于微服务架构服务被拆分成了多个独立部署的服务，并且每个服务之间需要进行依赖测试，在服务较多的情况下，怎么能有效的保证全链路上的服务都是按照约定的规则进行调用，这就成为了微服务实时过程中必须面临的挑战。
服务依赖管理
在单体应用架构下，由于业务功能比较集中，也不需要管理系统业务依赖。而在微服务架构下则不同，将不同的功能进行拆分之后，功能与功能之间肯定有很多相互依赖的地方，随着业务的不断增加，依赖与依赖之间的关系管理也将成为微服务的挑战。