微服务架构的整套解决方案
在当今微服务架构兴起的时代，微服务架构的软件产品数不甚数。在面对初步接触、从0到1开始的团队或个人，将面临很大的难题与困惑，技术框架如何选择、核心基础模块如何建设、都包含哪些东西，如何规范化等等问题。本文将针对微服务架构下面临的种种问题，一一罗列，提供整套解决方案，供大家参考。
1. 企业IT建设的三大基础环境
团队协作环境：主要是DevOps领域的范畴，负责从需求到计划任务，团队协作，再到质量管理、持续集成和发布。
个人基础环境：就是本文介绍的微服务应用平台，他的目标主要就是要支撑微服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。
IT基础设施：就是我们通常说的各种运行环境支撑如IaaS (VM 虚拟化)和CaaS (容器虚拟化)等实现方式。
2. 微服务应用平台总体架构
主要是从开发集成、微服务运行容器与平台、运行时监控治理和外部渠道接入等维度来划分的。
开发集成：主要是搭建一个微服务平台需要具备的一些工具和仓库
运行时：要有微服务平台来提供一些基础能力和分布式的支撑能力，我们的微服务运行容器则会运行在这个平台之上。
监控治理：则是致力于在运行时能够对受管的微服务进行统一的监控、配置等能力。
服务网关：则是负责与前端的WEB应用移动APP 等渠道集成，对前端请求进行认真鉴权，然后路由转发。
3. 微服务应用平台的运行视图
在运行期，作为一个微服务架构的平台与业务系统，除了业务应用本身外，还需要有接入服务、统一门户、基础服务等平台级服务来保障业务系统的可靠运行。图中的公共服务就是业务处理过程中需要用到的一些可选服务。
4. 微服务平台的设计目标
支撑微服务应用的全生命周期管理，包括从需求、设计、开发、测试、发布（自动打包管理和敏捷可靠发布）和运营（全面监控管理、标准数据采集和运营驱动创新）。
5. 微服务开发：前端、后端和混合
混合项目则是为了兼容传统模式而保留的，为企业应用向微服务架构演进提供过渡方案。
6. 服务契约与API管理
对于前面提到的微服务带来的依赖管理问题，我们可以通过平台提供的API管理能力来解决。服务契约有点类似于web service的wsdl描述，主要描述服务接口的输入输出规格标准和一些服务调用集成相关的规格内容。
7. 服务契约和服务模拟
有了服务契约，我们就可以根据契约自动生成服务的文档和服务模拟测试环境。这样，开发者就可以及时获取依赖服务的变化，调整自己的程序，并且能够方便的进行模拟测试验证。
根据契约生成模拟服务也就是我们常说的服务挡板，这样即使依赖的其他服务还无法提供功能，我们也可以通过挡板来进行联调测试。
8. 服务契约与服务编排
编排能够很大程度上简化分布式服务调用的复杂度，如同步、异步、异步模拟同步、超时重试、事务补偿等，均有服务编排引擎完成。
服务编排的作用和意义很大，可以快速的将已经提供的微服务能
力进行组合发布，非常适合业务的快速创新。
但是大家要注意，逻辑流编排的是业务流程，尽量能够简单明了，一眼看上去就明白业务含义。而业务规则推荐采用服务内部进行编码实现。千万不要将我们的“逻辑流” 图形化服务编排完全取代程序编码，这样就会可能会走入另外一个极端，比如设计出像蜘蛛网一样的逻辑流图，简直就是灾难。
9. 微服务容器
如果没有一个统一的微服务容器，这些能力在每个微服务组件中都需要建设一遍，而且会五花八门，也很难集成到一起。有了统一的微服务运行容器和一些公共的基础服务，前面所提到的微服务架构下部分组件重复建设的问题也迎刃而解。
10. 三方能力集成说明
微服务项目技术架构•API Doc: Swagger UI
•API Mock: Swagger Mock API
•AOP基础框架：Spring Framework
•微服务容器：Spring Boot
•服务发布：Spring Web MVC
•服务注册中心：Spring Cloud - Eureka
•服务路由：Spring Cloud - Ribbon

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。