洞见云原生微服务及微服务架构浅析

前言

2014年Martin Fowler正式提出了“微服务”的概念：微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下 文，选择合适的语言、工具对其进行构建。

Martin Fowler，软件开发领域教父级人物，ThoughtWorks首席科学家，著有《重构：改善既有代码的设计》《分析模式：可复用的对象模型》《领域特定语言》《企业应用架构模式》等经典著作，敏捷开发方法论开创者，微服务概念提出者**。**

---

一、单体架构与微服务架构

1、单体架构

一个单体系统是一个大而全的功能集合，每个服务器运行的是这个应用的完整服务。一个应用所有的功能都在一个工程项目里面，项目中的classes、jsp、css、js等前后端资源最终都归档为一个war包部署到服务器。

单体架构的优点：

• 开发、测试、部署都相对简单；
• 技术架构简单。

单体架构的缺点：

• 开发效率较低，开发人员往往需要了解整体业务功能
• 维护成本高，可扩展性较差
• 每次升级部署影响较大、所有服务都将不可用，牵一发而动全身
• 技术选型成本高

2、微服务架构

微服务架构是相对单体应用而言的，基于“低耦合、高内聚”原则，根据实际业务功能将单体应用拆分成多个服务，每个服务提供特定的业务功能（单一职责原则），每个服务都可以单独部署，相互独立。

微服务架构优点：

• 各服务根据高内聚低耦合原则拆分，代码更加简单易于理解
• 开发简单、只专注一个业务模块即可
• 易于扩展
• 前后端分离，易于部署

微服务架构缺点

• 运维部署复杂度提升
• 服务之间通过REST等方式互相调用，增加了通信成本
• 拆分导致的其他问题：如数据一致性问题，分布式事务问题等

单体架构与微服务架构并没有谁好谁不好的问题，只有适合不适合的问题。如果业务相对比较稳定，发版周期较长，则比较适合单体架构。而微服务架构在应对需求的变化、容错处理、服务复用及扩展、提升开发效率、简化交互等方面都有明显的优势。同时，敏捷开发、DevOps、持续集成/持续交付、容器技术、Spring Cloud框架、轻量级服务、领域驱动设计等技术的涌现也使微服务架构成为解决复杂问题的灵丹妙药。

二、微服务架构解决方案有哪些？

1. Spring Cloud：是一系列框架的有序集合，它利用Spring Boot的开发便利性巧妙地简化了分布式系统基 础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 Spring Boot的开发风格做到一键启动和部署。

   

2. Apache ServiceComb：是第一个 Apache 微服务项目， 是一个开源微服务解决方案,实现对微服务应用的高效运维管理。其提供一站式开源微服务解决方案，融合SDK框架级、0侵入ServiceMesh场景并支持多语言。

   

3. ZeroC IceGrid：ZeroC公司的杰作，继承了CORBA的血统，是面向对象的分布式系统中间件。基于 RPC 框架发展而来，具有良好的性能与分布式能力。

4. Motan：是开源的 RPC 框架，只支持 Java 语言实现，需要在 Client 端(服务消费者)和 Server 端(服务提供者)引入 SDK。

5. Thrift：是一种轻量级的跨语言 RPC 通信方案，支持多达 25 种编程语言。Thrift 有一套自己的接口定义语言 IDL

6. …

---

总结

微服务架构选型中，我们要根据社区成熟度、流行程度、开发难度、学习曲线、业务实际等多维因素考虑，微服务架构已在云原生架构中发挥着举足轻重的作用，而SpingCloud无疑是我们开发微服务的首选技术解决方案之一。

先自我介绍一下，小编13年上师交大毕业，曾经在小公司待过，去过华为OPPO等大厂，18年进入阿里，直到现在。深知大多数初中级java工程师，想要升技能，往往是需要自己摸索成长或是报班学习，但对于培训机构动则近万元的学费，着实压力不小。自己不成体系的自学效率很低又漫长，而且容易碰到天花板技术停止不前。因此我收集了一份《java开发全套学习资料》送给大家，初衷也很简单，就是希望帮助到想自学又不知道该从何学起的朋友，同时减轻大家的负担。添加下方名片，即可获取全套学习资料哦