文章插图
图4服务具有封装实现的API 。API定义了由客户端调用的操作 。有两种类型的操作：命令用来更新数据 ， 查询用来检索数据 。当服务的数据发生更改时 ， 服务会发布可供客户端订阅的事件
在本书第12章讨论部署技术时 ， 你将看到服务的实现视图可以采用多种形式 。该组件可以是独立进程 ， 在容器中运行的Web应用程序或OSGI包、云主机或Serverless技术 ， 等等 。但是 ， 一个基本要求是服务具有API并且可以独立部署 。
什么是松耦合
微服务架构的最核心特性是服务之间的松耦合性 。服务之间的交互采用API完成 ， 这样做就封装了服务的实现细节 。这允许服务在不影响客户端的情况下 ， 对实现方式做出修改 。松耦合服务是改善开发效率、提升可维护性和可测试性的关键 。小的、松耦合的服务更容易被理解、修改和测试 。
我们通过API来实现松耦合服务之间的协调调用 ， 这样就避免了外界对服务的数据库的直接访问和调用 。服务自身的持久化数据就如同类的私有属性一样 ， 是不对外的 。保证数据的私有属性是实现松耦合的前提之一 。这样做 ， 就允许开发者修改服务的数据结构 ， 而不用提前与其他服务的开发者互相协商 。这样做在运行时也实现了更好的隔离 。例如 ， 一个服务的数据库加锁不会影响另外的服务 。但是你稍后就会看到在服务间不共享数据库的弊端 ， 特别是处理数据一致性和跨服务查询都变得更为复杂 。
共享类库的角色
开发人员经常把一些通用的功能打包到库或模块中 ， 以便多个应用程序可以重用它而无须复制代码 。毕竟 ， 如果没有Maven或npm库 ， 我们今天的开发工作都会变得更困难 。你可能也想在微服务架构中使用共享库 。从表面上看 ， 它似乎是减少服务中代码重复的好方法 。但是你需要确保不会意外地在服务之间引入耦合 。
例如 ， 想象一下多个服务需要更新Order业务对象的场景 。一种选择是将该功能打包为可供多个服务使用的库 。一方面 ， 使用库可以消除代码重复 。另一方面 ， 如果业务需求的变更影响了Order业务对象 ， 开发者需要同时重建和重新部署所有使用了共享库的服务 。更好的选择是把这些可能会更改的通用功能（例如Order管理）作为服务来实现 ， 而不是共享库 。
你应该努力使用共享库来实现不太可能改变的功能 。例如 ， 在典型的应用程序中 ， 在每个服务中都实现一个通用的Money类（例如用来实现币种转换等固定功能）没有任何意义 。相反 ， 你应该创建一个供所有服务使用的共享库 。
服务的大小并不重要
微服务这个术语的一个问题是会将你的关注点错误地聚焦在微上 。它暗示服务应该非常小 。其他基于大小的术语 （如miniservice或nanoservice） 也是如此 。实际上 ， 大小不是一个重要的考虑因素 。
更好的目标是将精心设计的服务定义为能够由小团队开发的服务 ， 并且交付时间最短 ， 与其他团队协作最少 。理论上 ， 团队可能只负责单一服务 ， 因此服务绝不是微小的 。相反 ， 如果服务需要大型团队或需要很长时间进行测试 ， 那么拆分团队或服务可能是有意义的 。另外 ， 如果你因为其他服务的变更而不断需要同步更新自己负责的服务 ， 或者你所负责的服务正在触发其他服务的同步更新 ， 那么这表明服务没有实现松耦合 。你构建的甚至可能是一个分布式的单体 。
微服务架构把应用程序通过一些小的、松耦合的服务组织在一起 。结果 ， 这样的架构提升了开发阶段的效率 ， 特别是可维护性、可测试性和可部署性 ， 这也就让组织的软件开发速度更快 。微服务架构也同时提升了应用程序的可扩展性 ， 尽管这不是微服务的主要目标 。为了使用微服务架构开发软件 ， 你首先需要识别服务 ， 并确定它们之间如何协作 。现在我们来看看如何定义一个应用程序的微服务架构 。
4 总结
- 架构决定了软件的各种非功能性因素 ， 比如可维护性、可测试性、可部署性和可扩展性 ， 它们会直接影响开发速度 。
推荐阅读
- 十几年linux运维工程师的工作经验分享
- 现在程序员最火的微服务架构与SpringCloud，你真的弄清楚了吗？
- 春夏穿搭|韩国oni春季穿着分享
- 清明节气如何养生，分享五个小常识
- 我喜欢你很久了的说说 分享你最喜欢的一句话
- 自由职业者|工作10年，历经制造业和互联网行业，分享以下4点总结和感悟！
- 紫砂陶艺历代师承情况
- 八个月宝宝头发发黄怎么办
- 天蝎座|网友分享纯物理减肥法，感觉很厉害的样子，你觉得这样可行吗？
- 设计师必备的印刷常识
