高并发之应用拆分

比如一个股票系统有用户信息、开户、股票行情、交易、订单等，拆分后如下图所示：

原则

• 业务优先
  每个系统都会有多个模块，每个模块又有多个业务功能；按照业务边界进行切割，再对模块进行拆分。
• 循序渐进
  边拆分边测试，保证系统的正常运行。
• 兼顾技术：重构、分层
  不能为了分布式而分布式，拆分过程不仅是业务梳理也是代码重构的过程，根据技术进行分层来分配工作，ui对用户体验，熟悉C和C++对服务器，熟悉数据库的对数据库，做到术业有专攻，合适的人去做合适的事情。
• 可靠测试
  测试完毕后，才可进行下一步，每一步都要有足够的测试才可进行下一步，避免小错误引起蝴蝶效应。

思考

• 应用之间通信: RPC ( dubbo等)、消息队列
  消息队列通常用于传输数据包小但是数据量大，对实时性要求低的场景，比如下单后短信通知客户。而采用RPC要求实时性高，这里通常不会http或者service服务，原因是使用PRC调用service方法无感知，在配置好后和本地方法很像。
• 应用之间数据库设计:每个应用都有独立的数据库
  通常情况下，每个应用都有自己独立的数据库，如果共同使用的信息，可以考虑放在common中使用。
• 避免事务操作跨应用
  分布式事务是一个很消耗资源的问题，应用之间服务分开开发，能够保持相互独立。

框架

服务化 Dubbo

• 服务化 Dubbo笔记待整理
  

微服务Spring Cloud

• 微服务Spring Cloud笔记待整理
  
  微服务：独立的服务共同组成一个系统
  
  要实践微服务要解决4个问题：

1. 客户端如何访问这些服务
   API Gateway提供统一的服务入口，对前台透明，同时可以聚合后台的服务，提供安全过滤流控等api的管理功能
2. 服务之间是如何通信的
   异步的话使用消息队列，同步调用使用REST或者是RPC，Rest可以使用springboot，RPC通常使用Dubbo
   同步调用一致性强但是出现调用问题，REST一般基于http实现，能够跨客户端，同时对客户端没有更多的要求。
   RPC的传输协议更高效，安全也更加可控。特别是在一个公司内部如果有统一的开发规范和统一的框架，它的开发效率会更加明显。
   而异步消息在分布式系统中有特别广泛的应用，它既能减少调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方。
   同时保证调用方的用户的体验，继续干自己的活。付出的代价是一致性的减慢，需要接受数据的最终一致性
3. 如何实现如此多服务
   在微服务架构中一般每一服务都会拷贝进行负载均衡，服务如何相互感知，如何相互管理，这就是服务发现的问题了，一般都是进行服务注册信息的分布式管理。
4. 服务挂了该如何解决，有什么备份方案和应急处理机制
   分布式最大的特性就是网络是不可靠的，当系统是由一系列的调用链组成的时候，其中任何一个出问题都不至于影响到整个链路。
   相应的手段有：重试机制、应用的限流、熔断机制、负载均衡、系统降级