微服务（Microservice），一种用于构建应用的分布式架构框架，其解决了传统软件开发面临着很多的问题，比如：代码重复率高、代码庞大难以维护、无法快速迭代、测试成本高、可伸缩性差、可靠性差、模块间高度依赖等。

什么是微服务？

ThoughtWorks 首席科学家马丁·福勒（Martin Fowler）曾说过：微服务架构风格是以一组小服务来开发单个应用程序的方法，每一个服务运行在自己独立的进程中并且使用轻量的方法通信，通常是一个HTTP API接口。这些服务围绕相关业务范围构建并且由全自动化部署机器独立部署。这些服务只需要最低限度的管理，可以用不同的编程语言去编写并且使用不同的数据存储技术。

聊到微服务架构，不得不说说上一代传统单体架构。单块应用目前应用还是较多的，它部署容易，但任何改动都会牵一发动全身。哪怕是对应用程序一个小地方的改变，都需要整个单块应用被重新构建和部署。如要实现缩放，需要缩放整个应用程序而不是应用程序的某一部分，这要求更多的资源。

单体架构 VS 微服务框架

微服务架构的通用特性

根据MartinFowler的分析，微服务架构具有一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性。

• 1、通过服务实现组件化(Componentizationvia Services)：组件即可以被独立替换和升级的软件单；
• 2、围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队；
• 3、产品而非项目模式(Productsnot Projects)：“谁开发，谁运营”的开发运维一体化方法；
• 4、智能端点与管道扁平化(Smartendpoints and dumb pipes)：指采用轻量级异步通讯机制；
• 5、“去中心化”治理(DecentralizedGovernance)：使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术；
• 6、“去中心化”数据管理(DecentralizedData Management)；
• 7、基础设施自动化(InfrastructureAutomation)；
• 8、故障处理设计(Designfor failure)：容错机制；
• 9、演进式的设计(EvolutionaryDesign)。

为什么要采用微服务架构？

软件架构的发展经历了从单体结构、垂直架构、SOA架构到微服务架构的过程，各个架构的特点如下图所示：

各架构特点

相对于传统单体架构来说，微服务架构有着绝对的优势，企业应用向微服务架构演进的趋势不可逆转。

传统架构 VS 微服务架构

微服务架构的优点

• 1、每个服务都比较简单，只关注于一个业务功能。
• 2、微服务架构方式是松耦合的，可以提供更高的灵活性。
• 3、微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
• 4、每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
• 5、微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

• 1、运维开销及成本增加；
• 2、必须有坚实的DevOps开发运维一体化技能
• 3、隐式接口及接口匹配问题
• 4、代码重复
• 5、分布式系统的复杂性
• 6、异步机制
• 7、可测性的挑战

因此，企业应用架构使用微服务的先决条件要提前考虑到位。

使用微服务的先决条件

当软件的复杂度很低的时候，单体架构下的生产力是要高于微服务架构的，但随着复杂度的不断增加，无论是单体应用还是微服务应用的生产力都会下降，只是微服务架构的下降会相对缓慢一些。

如果长期业务规划不需要微服务架构或者团队不具备实施微服务一些基本的条件，不建议实施微服务，或者应用从试点入手，逐步在团队中推行微服务架构。

如何实施微服务架构

微服务架构4大设计原则：

· AKF拆分：AKF扩展立方体（Scalability Cube），是《架构即未来》一书中提出的可扩展模型，这个立方体有三个轴线，每个轴线描述扩展性的一个维度，他们分别是产品、流程和团队。

· 前后端分离：前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。

· 无状态服务：首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

· Rest 通信风格：作为一个原则来讲本来应该是个“无状态通信原则”，在这里推荐一个实践优选的 Restful 通信风格 ，因为他有很多好处：

• 1、无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案 HTTPS 可用。
• 2、JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
• 3、语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC 框架生态更完善。
• 4、当然在有些特殊业务场景下，也需要采用其他的 RPC 框架，如 thrift、avro-rpc、grpc。但绝大多数情况下 Restful 就足够用了。

行云系统设计的微服务实践

行云创新基于微框架 SpringBoot 实践，涵盖了微服务模块50个，多语言开发框架，多协议支持，并且应用基于容器技术等。

主要模块有：

Mart — 应用商店

Factory—应用工厂

Composer—设计器

APIGateway—API网关

Admin—运维中心

DNS—外部DNS服务

Orca—调度器

Blueprint Repo—蓝图存储

Internal DNS—内部DNS服务

Turtle —策略管理

Metrics—统计数据

Alert—监控告警

杭州—区域，包括容器集群等

Gateway—服务接入网关

行云 SpringBoot 实践架构图

总结

当前，以微服务、DevOps、容器、多云业务管理为代表的云原生技术已经广泛成熟应用，成为加速企业数字化业务高效创新、实现企业数字化转型的最佳技术支撑。而信创支持、国产化支持，是中国企业数字化转型不得不满足的基本要求。更有专家指出，在关乎企业生存的必选项“数字化转型”以及国家信创战略的共同冲击下，企业需要改变现有业务和IT的架构，更快速地应对挑战、响应变化，增强自身的竞争力。

-------------

免费获取《微服务实施指南》，请点击>