大话微服务架构

一:什么是微服务?什么是微服务架构??web

  微服务:数据库

微服务架构:是一种架构概念,旨在经过将功能分解到各个离散的服务中以实现对解决方案的解耦。你能够将其看做是在架构层次而非获取服务的。微服务架构是个颇有趣的概念,它的主要做用是将功能分解到离散的各个服务当中,从而下降系统的耦合性,并提供更加灵活的服务支持。服务器

二:微服务的好处??(不足)架构

  好处:框架

 在传统的IT行业软件大多都是各类独立系统的堆砌,这些系统的问题总结来讲就是扩展性差,可靠性不高,维护成本高。到后面引入了SOA服务化,可是,因为 SOA 早期均使用了总线模式,这种总线模式是与某种技术栈强绑定的,好比:J2EE。这致使不少企业的遗留系统很难对接,切换时间太长,成本过高,新系统稳定性的收敛也须要一些时间。最终 SOA 看起来很美,但却成为了企业级奢侈品,中小公司都望而生畏。分布式

首先,经过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的状况下,应用被分解为多个可管理的分支或服务。每一个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案,由此,单个服务很容易开发、理解和维护。

第二,这种架构使得每一个服务均可以有专门开发团队来开发。开发者能够自由选择开发技术,提供API服务。固然,许多公司试图避免混乱,只提供某些技术选择。而后,这种自由意味着开发者不须要被迫使用某项目开始时采用的过期技术,他们能够选择如今的技术。甚至于,由于服务都是相对简单,即便用如今技术重写之前代码也不是很困难的事情。

第三,微服务架构模式是每一个微服务独立的部署。开发者再也不须要协调其它服务部署对本服务的影响。这种改变能够加快部署速度。UI团队能够采用AB测试,快速的部署变化。微服务架构模式使得持续化部署成为可能。

最后,微服务架构模式使得每一个服务独立扩展。你能够根据每一个服务的规模来部署知足需求的规模。甚至于,你可使用更适合于服务资源需求的硬件。好比,你能够在EC2 Compute Optimized instances上部署CPU敏感的服务,而在EC2 memory-optimized instances上部署内存数据库。模块化

不足:微服务

其中一个跟他的名字相似,『微服务』强调了服务大小,实际上,有一些开发者鼓吹创建稍微大一些的,10-100 LOC服务组。尽管小服务更乐于被采用,可是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用,实现敏捷开发和部署。

另一个主要的不足是,微服务应用是分布式系统,由此会带来固有的复杂性。开发者须要在RPC或者消息传递之间选择并完成进程间通信机制。更甚于,他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。固然这并非什么难事,但相对于单体式应用中经过语言层级的方法或者进程调用,微服务下这种技术显得更复杂一些。

另一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很广泛。这种交易对于单体式应用来讲很容易,由于只有一个数据库。在微服务架构应用中,须要更新不一样服务所使用的不一样的数据库。使用分布式交易并不必定是好的选择,不只仅是由于CAP理论,还由于今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法,从而对开发者提出了更高的要求和挑战。

测试一个基于微服务架构的应用也是很复杂的任务。好比,采用流行的Spring Boot架构,对一个单体式web应用,测试它的REST API,是很容易的事情。反过来,一样的服务测试须要启动和它有关的全部服务(至少须要这些服务的stubs)。再重申一次,不能低估了采用微服务架构带来的复杂性。

另一个挑战在于,微服务架构模式应用的改变将会波及多个服务。好比,假设你在完成一个案例,须要修改服务A、B、C,而A依赖B,B依赖C。在单体式应用中,你只须要改变相关模块,整合变化,部署就行了。对比之下,微服务架构模式就须要考虑相关改变对不一样服务的影响。好比,你须要更新服务C,而后是B,最后才是A,幸运的是,许多改变通常只影响一个服务,而须要协调多服务的改变不多。

部署一个微服务应用也很复杂,一个分布式应用只须要简单在复杂均衡器后面部署各自的服务器就行了。每一个应用实例是须要配置诸如数据库和消息中间件等基础服务。相对比,一个微服务应用通常由大批服务构成。例如,根据Adrian Cockcroft,Hailo有160个不一样服务构成,NetFlix有大约600个服务。每一个服务都有多个实例。这就形成许多须要配置、部署、扩展和监控的部分,除此以外,你还须要完成一个服务发现机制(后续文章中发表),以用来发现与它通信服务的地址(包括服务器地址和端口)。传统的解决问题办法不能用于解决这么复杂的问题。接续而来,成功部署一个微服务应用须要开发者有足够的控制部署方法,并高度自动化。测试

三:传统开发模式与微服务的区别编码

  

 四:经常使用的微服务框架

相关文章
相关标签/搜索