我的架构师成长之路

今天我们来聊聊API集成，通过前两天的了解，我们了解到微服务是多服务，松耦合的服务集，既然涉及到了多服务，调用外部的API的必不可少的。 由于客户的多样性，设计应用程序的外部 API 变得更具有挑战性

昨天我们一起学习的微服务数据模式，今天我们来学习一下微服务的通信设计模式，通信是保证服务请求核心要素，选择合适的一个通信协议对系统来说可以达到事半功倍。 一、RPC调用模式 目前各种微服务通信社区上，

最近参与公司项目研发，在其中发现对于数据的管理存在一些小问题，根据以往经验，在这里记录下微服务数据设计模式。 微服务架构中的服务是松耦合的，可以独立开发、部署和扩展。每个微服务都需要不同类型的数据和存

如果您在设计大型并发应用程序或者准备拆解之前的老系统时，我想你第一考虑的是微服务架构方式。 前面我们了解到微服务架构将应用程序构建为一系列松散耦合的服务，是为了通过实现持续交付和灵活部署来加速软件开发

微服务系统相对于以往的单体系统更为复杂。在构建的时候，研发团队必须要管理和支持很多组件，环境会变得更加复杂。下面是我以往构建微服务系统时整理的一些主要挑战。 一、限界上下文 限界上下文概念起源于领域驱

微服务的缺点的优势 微服务是自包含的、独立的部署模块。 扩展的成本相对低于单体架构。 微服务是可独立管理的服务。它可以在需要时启用越来越多的服务，对现有服务的影响降至最低。 可以单独更改或升级每个服务

在写这篇博文时，我也不知道自己怎么走上软件架构师这条不归路的，记得当初我负责研发的时候，业务同事以及其他领导都说我是研发中最懂产品的，业务提出很多棘手的问题，我都可以帮忙解决。当我负责产品经理角色的时