最近阅读了几篇微服务架构的文章。对微服务的软件架构模式的优劣势，不敢贸然提笔。
众所周知，微服务架构存在风险，针对如何避免微服务架构的故障，提出了多种有效的微服务架构中的方法和技术。其中，例如，服务降级、变更管理、健康检查和修复、断路器和限流器等。
同时，微服务（micro services）这个概念不是新概念，很多公司已经在实践了。 例如，亚马逊、Google、FaceBook、Alibaba。微服务架构模式（Microservices Architecture Pattern）的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务。每个服务都可以很容易得到局部改良。 Micro这个词意味着每个服务都应该足够小。但是，这里的小不能用代码量来比较，而应该是从业务逻辑上比较。总而言之，符合SRP原则的才叫微服务。
暂且不讨论大小问题，谈到微服务，首先要考虑的是如何解决目前技术团队遇到的开发问题、部署问题。正是在解决这些问题的过程中，才渐渐总结提炼出了微服务架构模式的概念。
微服务跟SOA有什么区别呢？根据《微服务架构》图书详解，可以把微服务当作去除了ESB的SOA。ESB是SOA架构中的中心总线，设计图形应该是星形的，而微服务是去中心化的分布式软件架构。
本文试图尝试从几个侧面来解读微服务的定义、出现的背景。
1.微服务架构出现背景
《developerWorks 中国》对为什么需要微服务做了如下解读。首先， “微服务”架构是近期软件应用领域非常热门的概念。
让我们先来看看传统IT架构面临的一些问题：
使用传统的整体式架构(Monolithic Architecture)应用开发系统，如CRM、ERP等大型应用，随着新需求的不断增加，企业更新和修复大型整体式应用变得越来越困难；
随着移动互联网的发展，企业被迫将其应用迁移至现代化UI界面架构，以便能兼容移动设备，这要求企业能实现应用功能的快速上线；
许多企业在SOA投资中得到的回报有限，SOA可以通过标准化服务接口实现能力的重用，但对于快速变化的需求，受到整体式应用的限制，有时候显得力不从心；
随着应用云化的日益普及，生于云端的应用具有与传统IT不同的技术基因和开发运维模式。
此外，从技术方面看，云计算及互联网公司大量开源轻量级技术不停涌现，并日渐成熟：
互联网/内联网/网络更加成熟；
轻量级运行时技术的出现(node.js, WAS Liberty等)；
新的方法与工具(Agile, DevOps, TDD, CI, XP,Puppet, Chef)；
新的轻量级协议(RESTful API接口, 轻量级消息机制)；
简化的基础设施：操作系统虚拟化(hypervisors), 容器化(e.g. Docker), 基础设施即服务 (IaaS), 工作负载虚拟化(Kubernetes,Spark)等；
服务平台化(PaaS)： 云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务；
新的可替代数据持久化模型：如NoSQL, MapReduce, BASE,CQRS等；
标准化代码管理：如Github等。
这一切都催生了新的架构设计风格---微服务架构的出现。
2.什么是微服务
就像NoSQL，我们谈论了好几年的NoSQL，知道NoSQL的大致含义，但没有人能给微服务下一个准确的定义。
从业界的讨论来看，微服务本身并没有一个严格的定义。不过，ThoughtWorks的首席科学家——马丁·福勒（Martin Fowler）先生，对微服务的这段描述，似乎更加通俗易懂：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
加入云计算技术与物联网话题交流和深度思考，请扫描：
共有条评论 网友评论