转载请注明出自微信公众号：奔跑中的蜗牛
在这个开源的世界，实际上摆在我们面前的方案有很多。很多时候连架构师都难以选择。下面介绍三种典型的集群架构模型。
重客户端系
优势：
1、注册中心作为协调器，客户端和服务端直连，消费者和提供者只在服务启动时或者服务发生变化时才依赖注册中心，其余时间注册中心出现任何问题，服务发生变化之前都不会影响调用，注册中心压力较小；
2、客户端做负载均衡，生产者和消费者直连，中间无性能损耗；
3、SDK的方式，显然易用性得到保障。
劣势：
1、重客户端，以SDK的方式侵入系统。如果SDK升级，会比较麻烦；
很明显，这种模式非常普遍，由于zk的盛行，这种模式更加旺盛，例如dubbo、tddl、kafka……
代理系
优势：
1、代理上实际可以做负载均衡、容量规划、灰度发布等相关功能，但是像rpc、容错等相关功能必须在客户端来做，也就是需要SDK的支持。
2、降低连接数，如果按照每个消费者和生产者建立单链接计算，重客户端模式实际上有多少个消费者就需要生产者建立多少个链接，而代理模式可以让连接数降到只有生产者和代理的一个链接。
劣势：
1、多一层代理，性能上有消耗
2、增加一个不稳定因素
cobar属于这种模式，cobar和tddl都是数据库中间件，这两种模式有什么区别呢，如果单纯从数据库中间件这个层面来看，我更支持cobar，因为数据库通常用连接池和数据库建立链接，数据库又是服务化中最难以扩展的、有状态的节点，数据库的链接在大型应用中非常紧缺，汇聚链接是一个非常好的做法。
多级代理
优势：
1、同代理模式，代理上实际可以做负载均衡、容量规划、灰度发布等相关功能，但是像rpc、容错等相关功能必须在客户端来做，也就是需要SDK的支持。
2、代理分别与生产者、消费者放在同一容器中，proxy提取了大部分SDK的功能，proxy升级对应用无影响；
3、虽然1次请求变成3次，但是真正耗时的是网络间的那次通信，性能较一个代理要高；
劣势：
1、复杂度变高，这让开发、调试、部署都变得麻烦；
2、增加了两个不确定的点，对于稳定性来说是一个利空；
3、Proxy也需要占用资源，对cpu、内存、磁盘都有消耗；
总结：
重客户端这种模式不仅是在服务化框架中采用，很多中间件也采用类似的模式。侵入性本身和易用性就是相反的，而框架本身不但要起到服务化的作用，还要给开发人员提供方便，抽象通用功能，规范代码。或者把这些部分都扔给开发框架来做。
从KISS的原则来看，显然重客户端的方式更简单、美观；如果是PaaS平台，提供给第三方，从侵入性角度来说，多级代理也许是个好的选择（可以参见Kubernetes的结构）。否则你必须使用云平台提供的个性化SDK。如果从一个云迁移到另一个会比较麻烦。
Kubernetes强调的是容器级别的微服务，对于这个概念并不是特别清晰，到底什么样的才算微服务？单纯用开发人数来约定非常傻，用代码行数更傻，如果按照几百行的代码切分一个服务出来，那架构会变得异常复杂。我觉得大多数应用都是从集中开始一点点分裂的，服务化的分裂方式大多是业务相关性和团队规模决定的，当然如果都搞成细胞架构非常符合未来软件发展的趋势，只是如果切分的太小势必带来成本的增高，服务依赖的复杂性升高，可用性的提升必然带来一致性的降低。如果进化到微服务，依赖关系极其复杂的情况下，每个小小的改动都需要通知所有的调用者。在选择架构的时候，要谨慎选择。切分粒度是一个需要权衡的问题。这里内容很多，找个时间专门写一篇。
大多数互联网公司就算用云平台，大多也是使用IaaS平台，这意味着可以使用自己的服务化框架，dubbo必须是首选。除非将来像Kubernetes这种PaaS平台上诞生几个非常牛逼的项目出来，引领潮流。
更多文章欢迎关注奔跑中的蜗牛，