早想着要写一篇博客，但由于各种原因(其实因为懒)，迟迟没有动笔。今日下决心，写写关于软件服务架构的一点感悟。
三层架构
（图3）
软件并发量逐渐提高，不管是三层架构、还是微服务，优化的途径都差不多，读写分离-》加缓存-》分库分表。上方所示图2到图3，展示了利用一些数据访问中间件（Sharding-JDBC、Macat、Atlas&&）实现分库分表的架构。
重构
对于一个潜在的可能存在高并发场景的项目，如何能在遇到高并发的时候，从容地重构一个项目有一些浅见，供大家讨论：
（临时搭建的项目，凑合看吧）
如上图所示，项目划分了两个Package,一个Product，一个Membership,请注意，ProductController里面引用了Membership这个Package里的UserService，换句话说，就是ProductController依赖了Membership这个Package里的UserService。假如我们约定，不允许跨Package依赖，那么Product这个Package里有需要用到User相关的服务的时候，自己写到Product这个Package里。那么当我要进行服务拆分的时候，只需要把Product这个Package单独打包成一个jar，即可拆分完成。这样约定，方便从三层架构重构到上图2的架构，对将来可能的分库分表没有任何影响。
如果业务进一步复杂，采用图2所示架构也会遇到问题。比如库存数据，如果除了订单服务之外还有其他的服务都去修改库存数据的话，在没有统一日志或者这样的服务数量比较多的情况下，想要知道这个库存数据是怎么来的，会非常困难。这个时候只能重构成图1的架构。采用图1的架构，需要业务专家来定义接口，使其尽可能地适应多的使用场景。
出处：http://www.cnblogs.com/DKSL/p/9225178.html
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！