河北百度爱采购以最小化可行产品方式迭代推在持续开发系统的过程中，会有一些设计原则/经验可以用来遵循和指导我设计原则应该在系统迭代过程中，根据现有问题或特征匹配使用，如果刚开始遇到的不是核心问题，那么不要复杂化系统设计，但先行规划和设计是有必要的，要对现有问题有方案，对未来架构有预案1.1高并发原则1.1.1无状态果设计的应用是无状态的，那么应用比较容易进行水平扩展。实际生境可能是这样的：应用无状态，配置文件有状态。
    比如，不同的河北百度爱采购需要读取不同的数据源，此时，就需要通过配置文件或配置中心指1.1.2拆分在系统设计初期，是做一个大而全的系统还是按功能模块拆分系统，这个需要根据环境进行权衡。比如，做私塾在线时，本身用户量/交易量不会特别大，开发就笔者源有限，那就没必要对系统拆分（比如，拆分商品、订单等），做一个大而全的系统即可。而像设计京东秒杀系统，访问量是非常大的而且投入的资源还是蛮充足的，在这种情况下，就可以考虑按功能拆分系统笔者遇到的拆分主要有如下几种情况。系统维度：按照系统功能/业务拆分，比如商品系统、购物车、结算、订单系等功能维度：对进行功能再拆分，比如，优惠券系统可以拆分为后台券创建系券系统、用券系统等读写维度：根据读写比例特征进行拆分。比如，河北百度爱采购的各个系统都会读取数据，读的量大于写，因此可以拆分成商品写服务、商品读服务；读服务可以考虑使用緩存提升性能；写的量太大时，需要考虑分库分表；有些聚合读取的场景，如商品详情页，可考虑数据异构拆分系统，将分散在多处的数据聚合到一处存储，以提升系统的性能和可靠性AOP维度：根据访问特征，按照AOP进行拆分，比如，商品详情页可以分为CDN、页面渲染系统；CDN就是一个AOP系统模块维度：比如，按照基础或者代码维护特征进行拆分，如基础模块分库表、数据库连接池等；代码结构一般按照三层架构（web、 Service、DAO）进行划分。
    服务化首先，判断是不是只需要简单的单点远程服务调用，单机不行集群是不是就可以解决？在客户端注册多台机器并使用 Nginx进行负载均衡是不是就可以解决？随着调用方越来越多，应该考虑使用服务自动注册和发现（如 Dubbo使用ZooKeeper）。其次，还要考虑服务的分组/隔离，比如，有的系统访问量太大致把整个服务打挂，因此，需要为不同的调用方提供不同的服务分组，隔离访问。后期随着调用量的增加还要考虑服务的限流、黑白名单等。