服务拆分我引入我写的书上的内容来答复 我们从高内聚低耦合、业务模型、读写模式、演进式拆分、阶段性合并这些角度再来介绍服务拆分原则。1.高内聚、低耦合高内聚、低耦合是软件工程中的概念，在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准，这个标准在微服...

轻量的，无状态的服务应该都适合，比如web服务，不适合有状态的服务，比如缓存服务，数据库服务等，主要还是要看自身的需求

第一个问题：如果只是想把项目运行起来，用户总体量不大，并发不是非常大，那么任何框架都可以，比如springcloud，dubbo等。但是若需要精细化的做服务治理，那么很多就需要定制开发了。 第二个问题 ：单体架构向微服务架构转型的团队配置建议为多个小而美的团队，每个团队专门负责一组服务...

首先无论是单体架构还是微服务架构，项目都有可能出现失败的情况。相比单体架构，微服务架构更容易出现失败。以下场景容易失败：1、思想意识：当从单体架构转型微服务架构是首先从思想层面来培训，学会如何向有依赖的服务提交诉求，比如我需要某某接口完成某某功能，而不是自己去实现...

注册中心作为微服务的电话本，是非常重要的，无论在公有云、私有云还是混合云，注册中心都要具备高可用特性，因此需要在部署架构层面来执行。以混合云架构举例，公有云和私有云采用专线或网络的方式进行通信，因此在网络线路上要具备接入的高可用。层主的方案有两个。1、一套注册中...

（1）首先统一的redis中心是很“技术”，  因为你要一个强大的技术人员或团队；（2）为了保证一致性，redis cluster读取数据是从master上读取数据的，这样可以保证数据的一致性，当然，性能也就差了； redis 主从模式，写master节点，异步同步slave节点，读从slave上读取数据，读性能提高了，但一致...

恕我直言，你的招聘是要找开发总监一样的岗位，而且不是传统的开发，是基于微服务的springcloud的开发，应该是和金融有关的项目，但有个非常不合理，IT项目只有5年，架构师只有3 年。 这怎么可能， 起码要写10年以上。 如果一个新手，一开始就上手分布式，是不可能的啊。...

之所以采用微服务架构，无非两种场景，一是系统解耦，二是数据逻辑的拆分。针对共享底层架构的问题其实可以从服务的拆分来解释。 微服务化将服务进行拆分，通过网络服务进行通信，在这种情况下，会出现两个要解决的问题，一是微服务架构自身组件的性能损耗，还有个就是问题中所提到的底...

（1）更早期， 其实是基于企业总线的架构，很多的功能都在总线上实现，而服务都挂载在总线上。（2）而后出现了网关，由网关去分发访问请求，到下面的各种服务，而对服务的鉴权、限流、熔断等功能都是服务自己去实现，网关只是分发。这样会导致重复造轮子的问题。（3）而后，对服务的这些于共性的功...

首先判断自己擅长的语言以及团队擅长的语言，另外使用这门语言的人是否容易招聘，招聘成本是否高，另外这门选择的语言是否有开源的RPC框架，以及框架的使用情况和维护情况。