
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
随着互联网的不断发展,越来越多的程序员都在学习微服务架构技术,下面我们就通过案例分析来了解一下,微服务架构开发基础知识都有哪些。
微服务把单个进程的应用拆分为多个单独部署的服务。每个服务对外提供一些接口来进行服务间的通讯或者对三方提供功能。每个独立的服务甚至使用自己独立的存储技术,独立的语言技术栈。说到底微服务架构还是贯彻了软件开发中:单一职责、分而治之、解耦等基本理念,只是它把这种理念从类、类库级别提升到了进程级别。
微服务与SOA之间的区别网上有很多,在此不再大段的复制黏贴网上现成的文字,简单谈谈自己的一些理解。
先SOA大多数情况下是作用于企业内部,它通过ESB等总线技术把企业内的服务(或者称之为应用)串联起来。SOA虽然是在解耦、去中心化,但是它通常跟某种ESB技术强耦合起来,以至于ESB会成为那个大的中心。微服务的作用范围是应用而不是庞大的企业。微服务不在依赖ESB等总线技术,服务间的通讯通过无状态、轻量级的接口实现。协议采用http、json等通用协议无关开发语言,谁都可以调用。所以相比SOA有更好的去中心化意义。
上面说了这么多关于微服务的知识,那么实施微服务到底为我们带来了哪些好处?网上有很多复制黏贴的话其实我不太苟同,比如:部署简单,如果没有强大的运维团队微服务的部署显然是比传统单体应用部署难度更大了。比如快速开发快速迭代:事实上单体应用也不用等到完全开发完才能上线。
这个世界上的事情都是具有两面性的。微服务除了有其优点,自然也有缺点。我们在做架构的时候要尽量处理好这些缺点,避免踩到巨坑。
微服务在享受它带来的好处的时候也是有巨大的成本开销的。它会带来组织架构上的变动,人员的变动。它大大的提高了系统的复杂性,给运维、开发、测试、调试都带来巨大的挑战。
在采用微服务架构之前好先思考一下,真的需要微服务吗?权衡一下微服务带来的利弊再下决定。以我个人的经验来看,市面上绝大多数系统更适合单体架构,或者说没必要一上来就采用微服务架构。真正好的架构是在满足当前需求的前提下快速稳定的上线,并对后面的扩展、改造留好余地,以应对后面业务发展带来的需求进行架构的升级改造。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。