聊聊微服务的架构与应用-阿里云开发者社区

开发者社区> 开发与运维> 正文

聊聊微服务的架构与应用

简介:

1.微服务架构

微服务这个词越来越多的被提到,2014、15年的一波创业大潮,

很多创业公司需要短平快的产品开发,推动了敏捷开发、持续交付以及基于Docker的应用部署的发展,同时微服务结构也开始慢慢流行起来。

2.应用架构演进

(1)垂直应用架构

传统的LAMP架构和Spring+Struts+iBatis/Hibernate的架构都是典型的垂直应用架构,垂直应用架构学习成本低,开发产出快,测试、部署和运维比较简单,在过去的十几年中一直比较流行。
但是随着业务的发展,垂直应用架构逐渐暴露出一些缺陷,以Spring MVC架构为例,可能的表现:
1.复杂应用的开发维护成本越来越高,测试变得困难,部署效率越来越低。
2.团队沟通成本上升,协作变差,难以保证代码质量。
3.类似木桶效应,由于一些短板的存在,系统性能难以保证。
4.维护和定制变得困难,新功能上线周期变长,难以实现快速迭代。

(2)RPC架构

当垂直应用越来越多,应用之间交互不可避免,RPC可以提高业务复用及拆分。
当应用大规模服务化之后,会面临许多服务治理方面的问题。

(3)SOA服务化架构

SOA是一种粗粒度、松耦合的以服务为中心的结构,接口之间通过定义明确的协议和接口进行通信。

(4)微服务架构

微服务是一种服务化架构风格,通过将功能分散到各个离散的服务中以实现对解决方案的解耦。

3.微服务架构解析

(1)微服务的架构

微服务是指开发一个单个小型的但有业务功能的服务,每个服务都有自己的处理和轻量通讯机制,可以部署在单个或多个服务器上。
微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说,如果每个服务都要同时修改,那么它们就不是微服务,因为它们紧耦合在一起。

(2)微服务架构对比SOA

两者的主要差异如下:
1.服务拆分粒度
2.服务依赖
3.服务规模
4.架构差异
5.服务治理
6.敏捷交付


4.微服务架构的优点和缺陷

微服务的优点和缺陷就像一枚硬币的两面,要根据项目的实际情况合理的决定选用哪种架构。

(1)微服务的优势显而易见

1.避免系统无限膨胀
每个服务都很简单,只关注于一个业务功能,规避了原本复杂度无止境的积累。每一个微服务专注于单一功能,并通过定义良好的接口清晰表述服务边界。
2.独立部署
由于微服务具备独立的运行进程,所以每个微服务也可以独立部署。
3.微团队独立开发,扁平化管理
由于体积小、复杂度低,每个微服务可由一个小规模开发团队完全掌控,易于保持高可维护性和开发效率。
4.可以通过不同的编程语言与工具进行开发
不同的模块之间不用关系具体实现。
5.更好的扩展性
单块架构应用也可以实现横向扩展,就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时,微服务架构便体现出其灵活性,因为每个服务可以根据实际需求独立进行扩展。

7.容错性
当某一组建发生故障时,在单一进程的传统架构下,故障很有可能在进程内扩散,形成应用全局性的不可用。在微服务架构下,故障会被隔离在单个服务中。若设计良好,其他服务可通过重试、平稳退化等机制实现应用层面的容错。

(2)微服务架构的一些缺点

1.分布式系统的复杂性
作为一种分布式系统,微服务引入了复杂性和其他若干问题,比如网络延迟、容错性、消息序列化、不可靠的网络、异步、版本化、应用层中的负载变化等等。

2.代码重复
微服务强调小规模团队独立开发,不建议使用全局的公共类库。会在一定程度上造成代码重复。

3.测试繁琐
相比垂直应用架构,微服务的分散部署使测试变得繁琐。

5.微服务架构最佳实践

(1)使用分布式和自动化进行微服务运维

利用分布式系统的性能线性增长和弹性扩容能力,支撑大规模微服务对运维系统带来的冲击。
主要的如分布式性能数据和日志采集系统;
分布式汇总和计算框架;
分布式文件存储服务;
分布式日志检索服务等。

(2)基于Docker的容器化部署



本文转自邴越博客园博客,原文链接:http://www.cnblogs.com/binyue/p/3430204.html,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章