微服物概述

1.微服物框架概述

微服物是当前软件开发领域的热点，什么是微服物框架呢？与传统的单体应用有什么区别呢？解决了哪些问题？又带来哪些问题呢？

1.2.单体应用存在的问题

• 复杂度高。单个项目模块众多，代码质量参差不齐，每次对代码的改动都要做整体测试。
• 技术债务。随着时间推移，需求变更和人员更迭会逐渐形成应用程序的技术债务，并越积越多。
• 可靠性差。单个功能出现问题会影响整个应用系统。
• 扩展有限。单体作为一个整体应用，无法根据业务模块进行伸缩。
• 技术老旧。引入新技术困难。
• 部署频率低。单体应用中每次功能变更或BUG修复都会导致重新部署整个应用。

1.3.什么是微服物？

是一种架构风格，是一种将单一应用程序开发为一组小型服务的方法，具备以下特征：

a、每个微服务可独立运行在自己的进程里。

 b、单个微服务启动较快：单个微服务代码量较少，所以启动会比较快。

 c、局部修改容易部署：一般来说对某个微服务进行修改，只需要重新部署这个服务即可。

 d、技术栈不受限：在为服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。例如部分业务用关系型数据库，部分业务用NoSQL，部分用Java开发，部分用N​odeJS开发。

 e、按需伸缩：可根据需求实现细粒度的扩展。例如，系统中某个微服务遇到了瓶颈，可结合这个微服务的业务特点增加内存、CPU或增加集群节点等。

总结：每一个单个微服物，具备一个单体应用的所有特性，就是一个单独的单体应用。

1.4 微服务面临的挑战

 a、运维要求较高：更多的服务意味着更多的运维投入。

 b、分布式固有的复杂性：使用为服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。

  c、接口调整成本高：微服务之间通过接口进行通信。如果修改某个一个微服务的API，可能所有使用了该进口的微服务都需要做调整。

 d、重复劳动：很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候可能各个服务都会开发这一功能。

1.5 微服务设计原则

   和数据库设计中的N范式一样，微服务也有一定的设计原则：

   a、单一职责原则：一个单元（类、方法或这服务等）只应该关注整个系统功能中单独、有界限的一部分。单一职责原则可以帮助我们更优雅的开发、更敏捷的交付。

   b、服务自治原则：每个微服务应具备独立的业务能力、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部​署，都应该独立运行。

   c、轻量级通信机制：应具备体量较轻，跨语言、跨平台。重用的协议有REST、AMQP、STOMP、MQTT等。

   d、微服务力度：这块是个难点，也是争论的焦点。应当使用合理的粒度划分微服务，而不是一味的把服务做小。代码量的多少不能作为微服务划分的依据。 在设计阶段就应该确定其边界，微服务之间应保持相对独立并保持松耦合。

 

   e、微服务演进：微服务的演进是一个循序渐进的过程，会根据业务的变化进行重构，甚至重新划分，从而让架构更加合理。