For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
微服务架构开发是目前大多数软件开发程序员都在学习和使用的一种编程开发方式,下面我们就通过案例分析来了解一下,微服务架构开发优缺点分析。
所谓微服务架构风格是一种将单个应用程序开发为一组小型服务的方法,每个小服务运行在自己的进程中,并以轻量级的机制的方式进行通信,这些服务围绕着业务能力所建立的,并且可以由完全自动化的部署机构独立部署,这些服务的集中管理只有低限度,可以用不同的编程语言编写并使用不同的数据库存储技术。
1、微服务的优点
易于开发与维护
微服务相对小,易于理解;启动时间短,开发效率高
独立部署
一个微服务的修改不需要协调其它服务
伸缩性强
每个服务都可以在横向和纵向上扩展;每个服务都可按硬件资源的需求进行独立扩容
与组织结构相匹配
微服务架构可以更好将架构和组织相匹配;每个团队独立负责某些服务,获得更高的生产力,也更容易扩大开发团队
提高容错性
一个服务的内存泄露并不会让整个系统瘫痪
技术异构性
使用适合该服务的技术;降低尝试新技术的成本
2、微服务的缺点
团队沟通的过载
微服务架构降低了团队管理的难度,但是却不能降低团队沟通的需求。研发人员需要确保一个服务中的更新不会破坏其它功能。我们在单体应用中也会发现类似问题,但是微服务架构的应用这个问题会更加明显。
正式文档的过载
每一个独立的运行部件需要持续维护其规格和接口文档,这些文档是其它团队使用这些部件的必要条件。
不一致性的应用
我们可以为每一个组件选择不同的技术栈。这导致了不一致的应用设计和架构,而这会在更长期的运维期间增加系统维护成本。提炼代码脚手架统一的快速开发环境,运维起来更容易,但并不是银弹。
数据的复杂度
与单用户系统相比,连接到分布式系统的数据库是相当复杂和难以处理的,并且还有很多其他的数据源
DevOps的复杂度
我们需要拥有一支成熟的DevOps团队去处理微服务架构的应用的复杂性。由于多个应用存在多个活动部件,这种复杂度需要有高水平的经验。
增加了资源使用
运行这些微服务架构的应用的初始投资会比较大,因为所有微服务应都需要拥有他们自己的运行容器,这也需要更多的CPU和内存。另外采用了中间件也会带来一个比较大的资源投入。
增加了网络通信开销
分布式系统的产生的网络开销比单机应用多很多,不能简单把内部调用简单改为分布式调用,吃亏很大。微服务架构下,独立运行的组件都需要通过网络进行互相通信。这样系统需要有更加可靠和快速的网络连接。
网络安全
通过网络进行通信的系统更容易产生安全缺陷。
测试难度
测试微服务架构的应用绝对比单体应用难很多,深有体会,集成测试过程是一场噩梦。
产品监控
监控微服务架构应用的成本会更高,很难获得合适的工具,自研的成本也很高。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。