我的公司即将实施一种新架构,我们在其中提出BizTalk(我们是微软商店)作为SOA中的企业服务总线(ESB)(请不要引用面向服务的歧义)环境.
我们的业务是通过我们的新订单捕获GUI获取订单,该GUI必须连接到我们的客户数据库,产品目录,订购系统和其他一些辅助系统,每个系统都将作为WCF服务公开,然后将订单传递给我们的订单管理和其他下游系统实现,最后到我们的开票系统开发票.目前,每个系统都有自己的GUI,并使用手动过程在它们之间传递信息,以便自动化和集成自然思想,引入ESB来连接它们.
我对ESB的一些理由是,总线会担心如何连接系统(每个系统都是不可知的,对任何其他系统一无所知)以及如何格式化/翻译信息.很有可能在未来,一些现有系统将换成我们公司家族中的新系统或系统.
这似乎对我有意义,但我现在遇到了一些阻力,为什么在点对点解决方案足够时引入它.
不幸的是在公司历史上(在我预约之前)初步尝试引入BizTalk失败了,但我相信它有一个地方,我可以提供它.
我的问题可能不是关于BizTalk,而是在我描述的场景中ESB是否是一个好主意,何时引入ESB是有意义的？
这些我在编程世界中遇到了很多"横切要求/关注点".
虽然我觉得我知道这意味着什么,但我还没有一个明确的想法.我在Web服务和SOA中听到了很多.
可以使用hello world示例解释这个吗？
在WCF/SOAP世界中处理多态业务对象的正确方法是什么？
在我看来,SOA和OOP彼此不一致 - 要公开一个干净的WSDL,你需要具体的对象,通常甚至不利用继承.另一方面,可能在底层系统中,您需要遵循适当的OO设计.
人们通常在这做什么？构建一组WCF合同对象,放弃OOP原则,然后转换为实际逻辑层中的另一组对象？
我发现自己有责任继续开发一个我最初没有设计过的系统,并且无法向原设计师询问为什么会采取某些设计决策,因为它们不再存在.我是设计问题的初级开发人员,所以当我开始我的第一个SOA/WCF项目的项目时,我真的不知道该问什么.
该系统有7个WCF服务,将增长到9个,每个都在一个单独的控制台app/windows服务中自托管.所有这些都是单实例和单线程.所有服务都具有相同的OperationContract:它们公开Register()和Send()方法.当客户端服务想要连接到另一个服务时,他们首先调用Register(),然后如果成功,他们将使用Send()进行所有其余的通信.我们有一个DataContract,它有一个枚举MessageType和一个Content Propety,它可以包含其他DataContract"payloads".服务对消息的作用由枚举MessageType决定......一切都通过Send()方法传递,然后被路由到switch语句......我怀疑这是不寻常的
Register()和Send()实际上是OneWay和Async ...服务的所有结果都由WCF CallbackContract返回给客户端服务.我相信使用CallbackContracts的共鸣是促进我们正在使用的发布 - 订阅模型.问题不是我们的所有通信都适合发布 - 订阅并且使用CallbackContracts意味着我们必须在返回的结果消息中包含源详细信息,以便客户端可以计算出最初返回的结果...再次客户端有一个switch语句来解决如何处理基于MessageType(以及其他嵌入的详细信息)从服务到达的消息.
在拓扑方面:服务在图中形成"节点".每个服务都硬编码了它启动时必须连接的其他服务的列表,并且不允许客户端服务"注册"它,直到它完成所需的所有连接.例如,我们有一个LoggingService和一个DataAccessService.DataAccessSevice是LoggingService的客户端,因此DataAccess服务将在启动时尝试向LoggingService注册.直到它成功注册DataAccess服务将不允许任何客户端注册它.结果是,当系统整体启动时,服务以级联方式启动.我不认为这是一个问题,但这是不寻常的吗？
为了使事情变得更复杂,系统要求之一是服务或"节点"不需要彼此直接注册以便彼此发送消息,而是可以通过间接链接进行通信.例如,假设我们在链中连接了3个服务A,B和C,A可以通过 B ...使用2个跃点向C发送消息.
我实际上负责这个并编写了路由系统,这很有趣,但在我可以问为什么它真的需要之前,领先了.据我所知,没有理由不将服务直接连接到他们需要的其他服务.什么是更多我不得不写一个可靠的系统上的一切之上的要求是有可靠消息跨节点系统,wheras简单点至点链接WCF reliabily做这项工作.
在这个项目之前,我只使用winforms桌面应用程序3年,不知道更好.我的怀疑是这个项目过于复杂:我想总结一下,我的问题是:
1)图表拓扑的概念是否在间接链接上跳跃的消息不寻常？为什么不直接将服务连接到他们需要访问的服务(实际上我们正在做什么......我不认为我们有任何消息跳跃)？
2)在OperationContract中只暴露了2个方法,并使用MessageType枚举来确定消息是什么/如何处理异常？WCF服务不应该公开许多具有特定目的的方法,而客户端选择它想要调用哪些方法？
3)通过CallbackContracts进行的所有通信都回到了客户端.当然,同步或asyc请求响应更简单.
4)服务的概念是否不允许客户端服务连接到它(注册),直到它连接到它的所有服务(它是客户端)是一个合理的设计？我认为这是我同意的唯一设计方面,我的意思是DataAccessService在与日志服务建立连接之前不应接受客户端.
我有很多WCF问题,后面的主题会有更多问题.提前致谢.
所以我当天开放的潜在主观问题是; 如果您有机会今天在Microsoft技术上构建SOA; 你会从以下选项中选择什么？
出于个人和大学研究的原因,我正在考虑使用面向服务的架构构建一个简单的CRM.它的意思只是解释架构本身,而不是商业用途.
我正在考虑实施一个CRM,它提供简单的分析服务和客户服务(用户存储,个人评论和其他一些事情).
我正在设计的架构定义: - WebGUI(其他服务的客户端) - AnalyticsService(接收数据,分析和收集数据的服务) - CustomerCareService(使用RESTful API应用CRUD操作的服务).
每个服务都有自己的数据库,完全独立于其他服务.他们暴露了一个公共接口.当然,接口必须提供某种身份验证,以拒绝未经授权的请求.
我想在这种架构中解释的优点是可以让所有东西都独立,并且能够将它们组合起来提供新的服务(例如,如果有一个OrderService来处理订单,很容易将它与客户使用公共API).对我来说最大的好处是,构建使用这些服务的其他客户端很容易.
我不知道什么是一些好的身份验证方法,这可能很容易实现,我也不确定如何制作这个API(使用带有GET/POST数据的XML或普通REST API).我曾经使用亚马逊,PayPal和其他公司API,他们似乎使用REST服务(paypal使用丑陋的_cmd GET参数,而亚马逊使用更好的URI)知道该怎么做,但是阅读有关SOA的东西似乎人们也使用XML.当然,我还需要考虑到Web界面必须能够识别登录用户,获取权限(令牌或其他任何内容)并将其与服务一起使用以显示信息.所以我不确定SOA是我真正构建的那种架构......它是SaaS而不是SOA吗？我认为最好使用RESTful应用程序,使用JSON或类似的东西来实现它(我不是XML的忠实粉丝,我觉得它太冗长了).
为清楚起见,我在这里列出我的问题:
我有大约3个月的时间去做,所以我不能做一些真正复杂的事情(除了对单个程序员来说这是不现实的事实).
我知道Python(WSGI框架),Ruby on Rails,C/C++和其他语言(.net排除),我想在Linux环境下开发它(MySQL或Postgres,如果你有任何建议,甚至是NoSQL)正确的选择),我还可以将几种语言结合起来作为这些服务的独立程序.
我在这里想要的是有一些好的观点和一些好的建议.
谢谢!
我正在设计一个面向服务的体系结构,我还需要一个身份验证服务来识别客户端并允许它们访问资源.
其实我找到了两种可能的解决方案:
我没有假设oauth2服务,因为它会为我的需求增加太多设计系统的开销,而我更愿意采用更简单(但也很强大)的身份验证解决方案.
所以我来这里,我AuthenticationService可以通过发出API请求的客户端查询(获取与请求一起传递的令牌),或者由每个单个API端点查询以执行对签署请求的HMAC的反向检查查看它是否匹配(检查用于生成HMAC的私钥是否有效).
我可以看到最新的开发人员执行多个操作更简单,但它还需要更多检查来验证令牌并处理它的到期...
令牌解决方案可能会引发哪些潜在的安全问题,即单请求HMAC没有？你更喜欢什么,也可能是为什么？
我有一个采用微服务架构的相对较新的项目.除了我们的安全服务之外,我对各个服务的大小和粒度感觉相当不错.
我有三个主要的服务,让我们说foo-service,bar-service和baz-service.这些服务从不需要通信,但所有这三种服务都经常通过HTTP请求与之通信security-service.我希望这种情况因各种原因而停止 - 最大的问题是每个对我个人服务的请求都会产生对安全服务的请求,一旦你考虑到负载平衡等问题就会变成几个额外的跳跃.我一直在阅读Mark Richards撰写的"软件架构模式",他建议在这些情况下,您应共享数据库并违反DRY:将所需功能复制到每个服务中.不过,他将此示例用于较小的"实用程序"类,这可能不适用于此实例.
安全服务并不是那么大,所以我绝对可以将其复制到其他每个服务中.也就是说,它足够大,以至于我感觉很难复制并粘贴它 - 根据工作服的314'相关'代码行(java所以有更多的实际代码;-).我可以很容易地把它变成一个每个服务带来的模块 - 但是我的服务有一个共享的依赖关系,而且过去一直困扰着我.当然,随着我们添加身份验证方法,安全代码会随着时间的推移而增长,但是当涉及到auth时,我们并没有重新发明轮子,所以它主要与其他库和身份验证服务集成.也就是说,我不认为这个特定的代码库变得巨大.
所以我的问题是,我应该复制并粘贴代码还是构建每个服务带来的模块？谢谢!
我有2个域对象:项目和合同.一个项目可以有很多合同,所以在数据库中它被建模为一个典型的一对多关系.我们的问题是:你如何在微服务环境中对上述模型进行建模？你(a)有2个微服务ProjectService和ContractService吗？或(b)您是否有一个包含项目和合同的ProjectService？
我们认为答案(a)(即2个微服务ProjectService和ContractService)意味着必须调用2个服务来检索和保存完整的Project对象层次结构.另一方面,答案(a)完全将项目与合同分离,这在理论上可能是一件好事,但实际上没用,因为合同在没有项目的情况下不能在逻辑上存在.
这里的正确方法是什么？答案是(a)纳米服务反模式的一个例子吗？
在去年的大部分时间里,我的公司一直在根据(微)服务架构的原则切割整体并构建新产品.这一切都很好,并为我们提供了很大的灵活性,可以保持UI和后端逻辑的分离,并降低依赖性.
但!
由于这一点,我们的业务中有一个重要的部分,即报告.
由于我们确保服务之间没有数据复制(和业务逻辑共享),因此每个服务都知道自己的数据,如果另一个服务确实需要保留对该数据的引用,那么它们通过ID来实现(实体链接,基本上).虽然它很棒,但报道并不好.
我们的业务通常需要创建关于客户发生的特定实例的临时报告.在"过去的日子"中,您创建了一个简单的SQL查询,它连接了几个数据库表并查询了您需要的任何内容,但是对于解耦服务是不可能的.这是业务所看到的问题.
我个人并不是后端报告用途的数据复制的粉丝,因为这可能有另一种趋势,即成长为一场噩梦(它甚至已经存在于我们的传统巨石中).所以这个问题实际上不是关于传统的单块与现代微服务,而是关于数据依赖性.
您是否遇到过这样的问题,如果是,那么您是如何解决的？
编辑:
我们一直在内部讨论如何解决这个问题的几个潜在解决方案,但它们都没有实际上是好的,我没有得到我正在寻找的答案,但它解决了大规模的问题.
很好的旧复制 - 一切 - 让我们 - 人们 - 想出它是今天仍然习惯的东西.从旧的整体时代开始,BI /数据仓库团队制作了所有数据库的副本,但是同样的做法更加不方便,但到目前为止仍然使用数据库的所有微服务都做了.由于各种原因,这并不好,并伴随着你可以期待的共享沙盒癌症.
构建一个单独的微服务或一组用于获取特定报告的微服务.它们中的每一个都连接到设置微服务,其中包含相关数据并按预期构建报告.然而,这会引入更紧密的耦合,并且对于大型数据集而言可能非常复杂且速度慢.
构建一个单独的微服务或一组微服务,每个服务都有从后台其他数据库复制的数据库.这是有问题的,因为团队数据库正在耦合,数据被直接复制,并且强烈依赖于正在使用的数据库技术.
让每个服务向RabbitMQ发送BI服务可以接收的事件,然后根据需要获取其他数据.这听起来对我来说是最好的,但到目前为止最复杂的实现,因为所有服务都需要开始发布相关数据.这是我个人现在所选择的,从一个非常抽象的层面,就是这样.