微服务框架你了解什么（微服务概念已有10年之久）

微服务这个概念是在2012年出现的，作为加快web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年。

接下来我们聊一聊微服务架构的优缺点吧。

1、复杂度可控

微服务将一种怪异的整体应用程序分解成一组服务。虽然功能总量不变，但应用程序已分解为可管理的块或服务。每个服务都是以RPC或消息驱动的API的形式定义了一个明确的边界；微服务架构模式实现了一个模块化水平。

2、技术选型灵活

开发人员可以自由选择任何有用的技术，只要该服务符合API规范。这种架构使得每个服务都能够由专注于该服务的团队独立开发。

3、独立按需扩展

开发人员不需要协调部署本地服务的变更，这些变化可以在测试后尽快部署。

4、容错和可用性高

每个服务都可以独立调整，可以使用最符合服务资源要求的硬件来部署满足其容量和可用性限制的每个服务的实例数。

1、多服务运维难度大

微服务过于强调服务规模，但这只是一种手段，而不是主要目标。微服务的目标是充分分解应用程序，以便于敏捷应用程序开发和部署。

2、系统部署依赖、服务间通信成本高

随着服务的粒度越来越细，服务之间的依赖关系错综复杂；部署人员需要在众多微服务之间搞清楚他们的依赖顺序以及服务之间的通信。

3、数据一致性难度大

微服务中多个业务实体的业务交易是相当普遍的，你最终不得不使用最终的一致性方法，这对开发人员来说更具有挑战性。

4、测试微服务应用程序变得复杂

服务类的测试类将需要启动该服务及其所依赖的任何服务。

技术不是问题，意识比工具重要。微服务架构是核心，devops和docker是工具，是手段。

关于微服务架构的设计，需要从以下几点出发：

1、应用程序的核心是业务逻辑，按照业务或客户需求组织资源【这是最难的】

2、做有生命力的产品，而不是项目

3、头狼战队，全栈化团队

4、后台服务贯彻Single Responsibility Principle【单已职责原则】

5、所有服务需要具备：虚拟化部署、容器化部署、自动化部署的能力。

微服务架构不是目的，技术服务于业务。微服务架构应遵循三个标准和业务驱动力：

1、提高敏捷性：及时响应业务需求，促进企业发展；

2、提升用户体验：提升用户体验，减少用户流失；

3、降低成本：降低增加产品、客户或业务方案的成本。