本公司严格保护您的隐私并确保您的个人资料受到保护。本公司将定期更新隐私权政策，以遵循该个人资料保护法，请您参照我们最新版的隐私声明。本网站使用cookies以提供更好的浏览体验，如需了解更多关于本网站如何使用cookies 请按 这里。
人才招募
盟立集团提供各种职缺，包括技术职位和非技术职位
产品信息
2021.11.24
盟立微服务
微服务泛指数千个独立网络标准与网络协议、程序语言、数据库与网络服务器组件，以上各式不同组件存在于现行软件开发生命周期中，并做为开发人员工具使用。传统单体式架构将所有组件都写在一起，且基本上程序语言、Port与数据库等都采用同一套，而且彼此密不可分，微服务架构将应用拆解为最小单位的独立组件，彼此再透过API沟通、运行。
在微服务架构中，每个微服务都拥有各个微服务独立的作业，并使用轻量型通讯机制 (例如 REST API 要求) 与从属端或其他微服务通讯。
下图显示由多个微服务组成的应用程序架构：
举例来说，某个银行的报表系统中，有个子项目需要增加一个新的页面；若以传统的单体式架构开发，系统服务经过较长的时间过后，会因新增的功能与原有业务上或原有功能上的调整，产生调整逻辑时间花费较长的问题。且在过版的过程中，可能会有因新增的功能让整个系统需要暂时停止的问题。若改以微服务的架构进行维运与开发，则可以针对需要新增功能的子系统进行开发、过版时也不会因新增的功能而产生让整个系统需要暂时停止的问题。
微服务架构的优点：
微服务架构的挑战：
在微服务架构中，每个微服务都拥有各个微服务独立的作业，并使用轻量型通讯机制 (例如 REST API 要求) 与从属端或其他微服务通讯。
下图显示由多个微服务组成的应用程序架构：
举例来说，某个银行的报表系统中，有个子项目需要增加一个新的页面；若以传统的单体式架构开发，系统服务经过较长的时间过后，会因新增的功能与原有业务上或原有功能上的调整，产生调整逻辑时间花费较长的问题。且在过版的过程中，可能会有因新增的功能让整个系统需要暂时停止的问题。若改以微服务的架构进行维运与开发，则可以针对需要新增功能的子系统进行开发、过版时也不会因新增的功能而产生让整个系统需要暂时停止的问题。
微服务架构的优点：
- 可独立部署：微服务最显著的一个特征是，其服务规模相较于传统的单体式架构要小，而且可独立部署，因此不会有为了变更一段较小的功能，或在修复、调整功能时产生暂时暂停相关服务的可能。微服务保证可帮大型应用服务化解为了做小小变更而耗费大量时间的内心挫折。 不需要对应用服务有很深的了解，就能看出或了解能够进一步促进速度和敏捷的方法的价值。这一类型的服务设计方便的价值除了速度以外。 涉及商业问题、服务或产品的团队部门集结在同一大型服务下、也可以各部门专注于各自负责的组件。微服务模型可让组织针对单一服务或服务组合建立小型的跨部门团队，并让他们以敏捷方式运作。微服务的松散连结还可以建立一定程度的错误隔离，以及更好的应用程序复原力。 由于是小型服务，学习组件运作方式的学习成本可显著的降，加上其清晰的界限和通讯模式，使得新的团队成员更容易了解组件内的链接库并迅速做出贡献，就速度和员工士气来说都有显著好处。
- 精确扩充：有了微服务，个别服务不仅可以个别部署，在个别扩充的时候也比单体式服务更具弹性。 由此带来的好处显而易见： 只要能正确执行，微服务的基础架构需求低于单体式应用程序，因为它们能够精确地只扩充有需要的组件，而不是像单体式应用程序需要扩充整个应用程序，若项目需要时，亦可以让各个组件的团队照不同的情境，选择不同的程序语言。
- 敏捷的版本控管：因为微服务为独自部署，所以可更轻松地管理错误 (Bug) 修正和功能版本，相比之下，单体式架构较容易有修正时影响到原本正常功能的问题。 您可以径自更新服务，而不必重新部署整个应用程序，并于发生错误时复原更新错误的部份。 在许多传统应用程序中，如果在应用程序的某个部分找到错误，因各个不同功能均在同一个架构底下，这可能会封锁整个发行程序。 新功能可能会保留，等待整合、测试和发布的错误修正
微服务架构的挑战：
- 运维的复杂性：微服务的重大好处伴随着重大挑战。 从单体式移到微服务也意味着增加许多的管理复杂性与团队间的沟通顺畅程度； 更多的团队创造了更多的服务，然后部署在更多的地方，在项目的管理上也需要更多的沟通与协调，避免各自为政的问题。 某个服务发生问题可能导致其他服务发生问题，反之亦然。 记载应用轨迹数据（用于监视与解决问题）时，会变得更加浩瀚，而且可能在服务之间发生不一致，比方在A服务中，Token的状态改变了，但B服务没有更新Token的状态。 新版本可能造成后向兼容性问题。 应用程序涉及更多的网络联机，这意味着发生延迟和联机等网络或设备的问题的机会变更多。 DevOps 方法可以解决其中许多问题，但 DevOps 采用本身有自己的挑战。
尽管如此，这些挑战无法阻止非采用者采用微服务， 或阻止采用者深化其微服务承诺。新的 IBM 意见调查数据透露，56% 的非现行使用者可能在未来两年内采用微服务，而 78% 的现行微服务使用者可能会增加他们投入在微服务的时间、金钱和精力（如：图1）
- 技术的多样性：由于每个微服务都是一个独立的部署单元，各团队之间有相当的自由选择需要的技术。微服务可以用各种不同的语言，使用不同的库与程序框架，并使用不同的数据储存方式。这使得团队可以选择团队内部合适的工具来工作，有些语言和库更适合某些型别的问题。技术多样性通常以最佳符合专案情境或是整个项目中最多成员熟悉的工具为中心进行讨论，但往往微服务最大的好处却是更令人头疼的版本问题。在单体架构中你可以只使用一个单一的版本库，这种情况经常导致升级出现问题。系统的一部分可能需要升级，来实现使用它的新功能，但不能因为升级而中断系统的另一部分。处理链接库或程序框架的版本问题是其中的一个难题，因为随着程序代码库的增大，难度会呈指数级增长。
这里有一个风险，有这么多的技术多样性，开发团队会被压倒。一般来说，大多数组织都鼓励有限的一组技术。这种鼓励是通过提供共同的工具来支持监测，使它更容易将服务稳定在一个小的通用环境中。用单体架构系统，早期对语言和框架的决定是很难逆转的。经过十年左右，这些的决定可能会限制团队并使团队陷入尴尬的技术境地。微服务让团队尝试新工具，并逐步一次迁移系统的一个个服务，使新老技术有所关联，在重构服务架构时不必一次将全部的功能与组件都完成，而可以较平滑的完成重构。 - 其他因素：微服务的支持者们经常说服务更容易扩充套件：若一个服务会有大量的负载，就可以针对需要的独立套件进行扩充，而不用对整个应用进行扩充套件。微服务允许你隔离敏感数据以及给数据增加安全性。此外，在保证微服务间互动安全的前提下，微服务相较单体式服务架构是难以被攻入的。安全问题越来越重要，这可以成为使用微服务的主要考虑因素。