分布式系统基础设施概览

DB当然是第一重要，但是具体到选择oracle/mysql/postgresql亦或是mongodb，就需要有足够的的经验，主要要考虑如下点：

1、提供的feature是否足够丰富，能否满足OLTP/OLAP的需求；

2、是否支持高并发、HA机制（各优缺点、维护能否跟上、对开发有什么额外要求），这里又涉及到对硬件的要求，应用层有什么特殊要求；

3、能支撑什么数量规模的，水平拆分容易程度；

4、对于open source，还要考虑选择mysql/percona/mariadb分支，与标准的兼容性；

5、社区活跃性、稳定性、当前可用版本有哪些关键特性无法满足业务需求；

 

web/服务端容器

web容器应该来说绝大部分非国企性质都是使用tomcat。但是对于不提供web服务的服务端容器，因为通信由rpc中间件完成了，所以作为托管容器而言，不太适合使用tomcat/weblogic之类的web容器，主要是不仅占用额外资源，更主要的是每个容器至少需要三个端口，外加rpc端口的话，可能一个runtime需要五六个端口，对于一个server上运行多个Instance的情况，端口的管理和规划很快就会成为一个噩梦。所以其实选择os service托管会是更好的选择，比如java service wrapper，而且它会作为deamon进程，jvm进程异常挂掉时会自动重启。

 

RPC中间件。对于分布式系统而言，一个好的RPC中间件是非常重要的，这直接决定了整个系统的扩展性、灵活性。一个好的RPC中间件至少应该满足以下条件：

1、支持在RPC本地根据规则，比如说功能号进行路由，路由的目标可以是本地也可以是远程；

2、基于长连接，一般为TCP；

3、再不济，性能也不能低于HTTP；

4、支持自动负载均衡，连接恢复；

5、支持服务注册中心服务自动发布，服务注册信息自动拉取；

6、RPC客户端支持API依赖注入，RPC服务端支持根据注解发布和路径；

7、绝大部分情况而言，应该是不需要跨语言的，根据特定语言去做说不定更合理；

RPC框架的设计与实现参考可见http://www.cnblogs.com/zhjh256/category/911531.html

选择基于服务的设计之后，应该同时纳入考虑的就是RESTFUL API/OPEN API的规划和管理了。

 

分布式缓存/DB。分布式缓存最常用的场景是分布式session，客户信息、产品信息等相对而言比较静态的数据。当然，它远远不止用于这里。

1、支持集群；

2、TPS 50000以上；

3、支持常规以外的list/hash/set结构；

Redis 3之后就比couchbase要更加合适了。

 

消息中间件。消息中间件是重要性等同于分布式缓存的中间件。对于大型的分布式系统而言，通常关键的业务场景在同步执行时会存在着致命的瓶颈。一个好的消息中间件应该至少满足下列条件：

1、支持集群；

2、支持持久化；

3、4C下TPS 5000以上稳稳的（还跑了很多其他进程）；

4、支持可信发布、订阅；

5、有管理API可监控队列，队列中内容等；

6、支持广播、点对点、主题；

rabbitmq是比较合适的，而且现在来看，稳定性是相当好的。

提到消息，不能不提及的是websocket，根据业务高度封装websocket集成到应用框架中是非常有价值的。