了解应该与其他业务部门共享多少微服务基础架构

时间:2018-01-22 16:08:01

标签: architecture microservices

通常最好部署单独的微服务基础架构,包括 容器调度程序,团队/产品等大型组件?

我觉得这很大程度上取决于组织的结构 和文化很像 this 文章建议。我们的组织是等级的,区域不同 负责不同专业的分支机构(数据库,操作系统管理,开发, 质量保证都有不同的经理甚至董事。这些领域自然而然 有不同的优先事项,并存在一些知识差距 它们之间。尽管如此,感受到了快速交付的压力 市场压力和监管义务。

作为一名软件开发人员,我非常喜欢松散耦合的想法 相信我们的团队应该有自己独立的容器实例 管理平台。我们的团队应该是多功能的,能够提供 自己生产。我可以想到这种方法的几个优点:

  • 我们将负责环境的同质性
  • 更快的迭代次数
  • 风险分散在几个基础设施/团队而不是一个 巨型巨型实例
  • 考虑到时,从等式中删除外部团队 内部更改/升级到您的平台

1 个答案:

答案 0 :(得分:0)

在网络级别,总有一定程度的共享基础架构,如果没有别的话。我认为关键是以这样的方式共享基础架构,这样它就不会损害您独立于其他团队部署微服务的能力。例如,如果您共享某些基础架构(如数据库),那么数据库团队应负责管理服务器(硬件,复制,监视,资源分配等),并且微服务团队应该拥有其数据库的所有权,包括改变它的架构的能力。对基础架构的更改仍然会破坏您的微服务,例如数据库服务器版本更新,但您不太可能通过更改破坏基础架构。您也真的不希望自己处于需要向外部团队提交更改请求以运行脚本来更新架构的位置,因为这取消了采用微服务架构的关键优势。另一种方法是建立一个结构,为每个微服务团队分配一个有权及时更改基础架构的团队成员,但这并不一定意味着也不会出现延迟和冲突。

你应该尽量避免的是,整合'您的微服务通过基础设施,例如使用相同数据库模式/实例的两个明显独立的微服务。除了将微服务与基础架构耦合之外,您还需要紧密配合您的微服务,这极大地影响了您的部署能力。