为什么开发后端微服务时要分离API模块？基于组件模型的架构(EJB)层次架构(MVC)面向服务的架构(SOA)3 .微服务特点(1)系统由多个服务组成(2)每个服务都可以独立部署(3)每个服务都是松耦合的。
微服务该如何设计缓存？
笔者做过公司多个项目的微服务架构和改造，就微服务的缓存设计这个问题来发表一下自己的看法。从3个层面来回答这个问题：为什么用缓存？什么场景下使用缓存？基于缓存的架构设计点1.为什么用缓存在高并发场景下，如果直接读DB，很容易出现性能瓶颈，因此需要通过缓存来减少DB的压力，使得大量的访问进来能够命中缓存，只有少量的需要读DB，
缓存基于内存，可支持的并发量远远大于基于硬盘的数据库。所以对于高并发设计，缓存的设计必不可少，2.什么场景下使用缓存我们都知道缓存可以提升系统响应速度，那么一般哪些场景下需要用到缓存呢？我们可以列举3个场景：2.1计数缓存计数对于数据库来讲，是非常繁重的任务，需要查询大量的数据，最后得出计数结果，当数据改变的时候，需要重新刷一遍，非常影响性能。
因此可以设计一个计数服务，后端对接缓存，将计数作为结果放在缓存里面，当数据改变时，调用计数服务增加或者减少计数，计数服务可以使用Redis进行单个计数，也可以用hash表进行批量计数。微服务中的使用场景为网关中的流量控制、配额控制等计数服务，2.2频繁读 低频写比如一个网上商城，商品品类信息的更新品类相对而言是比较低的，但是几乎所有商品相关的查询服务都需要读取商品的品类信息。
像这种低频写、高频读的数据，比较适合放到缓存中，来提升服务性能，2.3较大内容的高频读数据这个和2.2的主要区别是防止在缓存中的量级。比如物联网场景中的白名单信息，接入物联网的设备量级一般比较大，可以到万、千万甚至上亿级别。对于这些设备的白名单控制不可能每次都读取DB来做权限验证，因此需要设计针对大量数据的分布式缓存来提升服务性能。
3.基于缓存的架构设计点基于缓存的架构设计点可以从2个方面来考虑：3.1分场景要区分缓存的实际应用场景，来进行不同的缓存技术选型，对于微服务网关中的流量控制所用到的分布式缓存，可以使用redis 本地缓存技术的方案。对于商品分类信息的存放，使用本地缓存就可以满足需求，对于大型文件的缓存，则推荐本地文件 本地缓存的方式，配合版本管理实现。
3.2缓存架构的高可用引入缓存是为了解决性能瓶颈，但是实质上是引入了更多依赖，比如使用redis，如果没有足够的容错机制，redis一旦挂了，则会导致服务不可用。可以使用分片，这样每一个缓存实例都不大，但是实例数目比较多，一方面可以实现负载均衡，防止单个实例称为瓶颈或者热点，另一方面如果一个实例挂了，影响面相对会小很多，高可用性大大增强，
Java后端微服务开发，为什么要单独把api模块分离出来？
现在的软件开发模式和传统的有很多差别，传统的开发模式耦合度较高，随着技术的发展越来越多的开发模式被应用，比如微服务架构模式。其实很多开发语言都有自己的微服务解决方案，如Java系的SpringBoot、SpringCloud等，但在实际项目开发中，即使是在微服务开发模式下，依旧有很多人喜欢单独抽离出一个api模块，这是为什么呢？什么是微服务？其实“微服务”并不是一种新的技术，而是一种新兴的架构模式。
简单来说，就是把一个服务拆分成多个粒度小、易于复用的子服务。这样做的好处是:应用/服务解耦，避免了单一业务的复杂性；每个微服务都是独立开发部署的，扩展性更强，可以实现服务的高可用性；基于组件且易于复用，开发后端微服务时为什么要分离API模块？既然是微服务模式开发项目，为什么很多开发者会习惯性的搭建一个API模块？其实在开发微服务时，可以采用单模块模式开发，而很多人因为遵循“高内聚、低耦合”的设计模式，所以采用多模块开发。这样做的好处是:1。界限清晰，易于管理。一个中等规模的项目，在开发的时候会有很多业务和模块，分散在各个包里，非常混乱。
