按关键词阅读： 数据库 数据格式 API HTTP 微服务
每个人都在谈论微服务 。 行业资深人士可能会记住单片或基于SOA的解决方案是做事的方式 。 时代变了 。 新工具使开发人员能够专注于特定问题 ， 而不会给部署或通常与隔离服务相关的其他管理任务增加过多的复杂性 。 选择使用合适的工具来解决正确的问题变得越来越容易 。
在本系列文章中 ， 我们将探讨微服务的世界 ， 它如何帮助解决现实问题 ， 以及为什么行业越来越多地将其作为标准的做事方式 。 在本系列中 ， 我们将尝试解决与此方法相关的常见问题 ， 并提供方便简单的示例 。 在本系列的最后 ， 我们应该有一个完整的基于微服务的架构的框架实现 。 今天 ， 我们将关注微服务以及它们与替代方案的比较 。 我们还将列出我们计划在以下帖子中讨论的问题 。
更新：在第2部分中 ， 我们讨论了API网关 。
什么是微服务？微服务是一个孤立的 ， 松散耦合的开发单元 ， 可以解决一个问题 。 这类似于旧的“Unix”做事方式：做一件事 ， 做得好 。 诸如如何“组合”服务提供的任何事项的事项留给更高层或政策 。 这通常意味着微服务往往避免相互依赖：如果一个微服务对其他微服务有一个硬性要求 ， 那么你应该问自己是否有意义将它们全部放在同一个单元中 。
"A microservice is an isolated, loosely-coupled unit of development that works on a single concern."
“微服务是一个孤立的 ， 松散耦合的开发单元 ， 可以解决一个问题 。 ”
文章插图
微服务对开发团队特别有吸引力的是他们的独立性 。 团队可以自己处理问题或一组问题 。 这创造了许多开发人员青睐的有吸引力的品质：
- 自由选择合适的工具：您一直想要使用的是新的库或开发平台吗？你可以（如果它是适合这项工作的工具） 。
- 快速迭代：第一个版本不是最理想的吗？没问题 ， 版本2可以立即出门 。 由于微服务往往很小 ， 因此可以相对快速地实现更改 。
- 重写是一种可能性：与单片解决方案相比 ， 由于微服务很小 ， 重写是可能的 。 技术堆栈是错误的选择吗？没问题 ， 切换到正确的选择 。
- 代码质量和可读性：隔离开发单元的质量往往更高 ， 新开发人员可以非常轻松地使用现有代码 。
必须以这样的方式实施跨领域关注 ， 即微服务不需要处理有关其特定范围之外的问题的细节 。 例如 ， 身份验证可以作为任何API网关或代理的一部分来实现 。
数据共享很难 。 微服务倾向于支持可以直接更新的每服务或每组数据库 。 在为您的应用程序进行数据建模时 ， 请注意这种处理方式是否适合您的应用程序 。 为了在数据库之间共享数据 ， 可能需要实现处理数据库之间的内部更新和事务的内部过程 。 可以在许多微服务之间共享单个数据库;请记住 ， 如果您需要在将来进行扩展 ， 这可能会限制您的选择 。
可用性：由于隔离和独立 ， 需要对微服务进行监控 ， 以尽早检测故障 。 在一个大型软件堆栈中 ， 一个服务器可能会被忽视一段时间 。 在选择用于管理服务的软件堆栈时考虑到这一点 。
进化：微服务往往快速发展 。 当专门团队处理特定问题时 ， 可以快速找到新的更好的解决方案 。 因此 ， 有必要考虑服务的版本控制 。 只要有客户需要使用旧版本 ， 旧版本通常可用 。 较新版本以特定于应用程序的方式公开 。 例如 ， 使用HTTP / REST API ， 微服务的版本可以是自定义标头的一部分 ， 或嵌入在返回的数据中 。 说明这一点 。
自动部署：现在微服务如此方便的全部原因是 ， 从完全干净的环境部署新服务非常容易 。 请参阅Heroku ， Amazon Web Services ， Webtask.io或其他PaaS提供商 。 如果您要采用自己的内部方法 ， 请记住 ， 部署新服务或预先存在的服务版本的复杂性对于解决方案的成功至关重要 。 如果不以方便 ， 自动的方式处理部署 ， 您最终可能会达到一定程度的复杂性 ， 这超出了该方法最初带来的好处 。
相互依赖性：将它们保持在最低限度 。 处理服务之间的依赖关系有不同的方法 。 我们将在稍后的博客文章系列中进一步探讨它们 。 现在 ， 请记住 ， 依赖性是这种方法的最大问题之一 ， 因此寻求将它们保持在最低限度的方法 。
稿源：(未知)
【傻大方】网址：http://www.shadafang.com/c/111J2T942020.html
标题：数据格式|[微服务架构 】微服务简介，第1部分