薛大龙系统集成项目管理工程师考试学习笔记

混乱的实现

微服务架构下推荐使用REST作为服务间同步通信的方式，对于非实时需求，可以基于事件来实现异步协作。这个原则非常简单，也非常容易实现，然而仅遵循这个原则却很难让我们沿着微服务的道路走下去。一些号称微服务架构的系统，最初服务拆分并无太大问题，但随着逻辑的不断扩展，跨服务数据交换场景的增加，这个简单的原则就很难指引日常的决策，甚至引发了一些新的问题，举几个例子：

服务循环依赖

在一些场景下服务A依赖服务B，会调用服务B的API，而在另外一些场景下，服务B也需要服务A的数据，也会通过调用服务A的API来实现。单从实现层面来看，按需获取数据，实现很方便，可以完成业务要达成的效果；但从长远来看，两个服务的耦合越来越紧，未来新增需求的实现成本会越来越高，成为技术债

第三方系统集成实现到业务服务中

在一些业务场景下，当前产品需要的业务数据需要从几个第三方系统获取并进行整合甚至经过一些计算后才能使用，之前的一些项目在初期实现时，数据从第三方系统获取后，经过处理直接写入业务数据库，就把集成的代码直接写到业务服务中，看起来并没有太大的问题，只要代码上做好隔离就好了。但实际上，后期发生了一些棘手的问题让我们不得不作出改变：

一些定时触发的集成任务，每次只会在一个服务实例上运行，在运行期间可能会有大量的数据读取、计算、更新、插入等操作，会短时大量占用当前服务实例的资源，严重的情况下当前服务实例甚至无法正常对外提供服务

相似的集成以同样的方式集成到业务服务中，比如不同品牌的产品库存会从多个第三方系统获取，业务服务变的臃肿

集成方的一些变化直接影响到业务服务，比如API的升级，这种改变必须要重新升级部署业务服务才能完成