浅谈微服务架构的设计模式

微服务架构模式（MicroserviceArchitectPattern）。近两年在服务的疯狂增长与云计算技术的进步，让微服务架构受到重点关注

微型服务体系结构是一种体系结构模式，它主张把单个应用分成一组服务，这些服务相互协调，相互协作，为用户提供最终价值。每一个服务都在其独立进程中运行，并且服务和服务之间采用轻量级通信机制(通常是基于HTTP的RESTfulAPI)来相互交流。每一个服务都是围绕特定的业务构建的，并且可以独立地部署到生产环境，类生产环境等等。此外，还应尽量避免统一的、集中的服务管理机制，对于特定的服务，应根据业务上下文，选择适当的语言、工具来构建。

微服务架构优势

本文首先简要介绍了微服务(Microservices)的内涵和优势，微服务体系结构的本质，就是使用具有更多明确功能和更多复杂业务的服务来解决更大的实际问题。微型服务体系结构将服务分开，采用相对独立的服务对各个方面进行管理，彼此使用统一的接口进行通信，体系结构变得复杂，优点也十分明显：

复杂性控制：在运用分解的同时，避免无限制地累积原来的复杂性。每个微服务都关注单个功能，并通过定义良好的接口清楚地描述服务边界。因为这些微服务都很小，复杂度很低，所以每个微服务都可以被一个小型的开发团队完全控制，很容易保持高的维护性和开发效率。

你可以点击加入这个群：Java高级架构入门群：854180697里面有Java高级大牛直播讲解知识点走高端路线，(如果你想跳槽换工作，但技术不够好，或工作遇到瓶颈，我这里有一个JAVA的免费直播课程，讲的是高端知识点基础不好的误入哟，只要你有1-5年的开发经验可以加群找我要课堂链接，注意：这是没有开发经验的免费直播课程哦)

微服务架构

单独部署：因为微服务有独立的运行流程，所以每个微服务也可以单独部署。在更改某些微服务时，不需要编译和部署整个应用程序。包含微服务的应用程序相当于具有一系列可并行的发布过程，这使得发布更高效，同时减少生产环境中的风险，并最终缩短应用程序的交付周期。

灵活的技术选择：在微服务体系结构中，技术选择是去中心化的。每一个团队都可以根据自己的服务需求和行业发展现状，自由选择最合适的技术组合。因为每一个微服务都比较简单，所以在需要升级技术栈时风险就会降低，甚至可以完全重构一个微服务。

容错：当一个组态出现故障时，在传统的单进程结构中，故障很可能在进程中扩散，并形成应用程序无法使用的全局性。在微服务体系结构中，故障被隔离在一个服务内。如果设计良好，其他服务可以通过重试、平滑退化等机制在应用层上实现容错。

扩展性：单一体系结构应用也可以实现横向扩展，即完整地复制整个应用到不同节点。微服务架构在应用的不同组件之间存在着扩展需求差异的情况下表现出灵活性，因为每个服务都可以根据实际需求独立地扩展。

互联网高并发相关名词。

页面浏览数（pageviews）

唯一身份浏览量（UniquePageViews）

独立访问者数量（uniquevisitors）

重复访问者数量（repeatvisitors）

每个访问者的页面浏览数（PageViewsperuser）

高并发

以前我把高并发解决方案误认为线程或队列就可以解决，因为高并发时有很多用户在访问，导致出现系统数据不正确、丢失数据的现象，所以想到了用队列解决方案，其实队列解决方案的方式也可以处理，比如我们在竞拍商品，转发评论微博或是秒杀商品，同时访问量特别大，队列在这一点上发挥着特殊的作用，把所有的请求都放到队列中，按毫秒计时器，有序地进行，这样就不会出现系统中数据不正确的情况。

通过查阅资料，高并发性解决方案有两个，一个是使用缓存，另一个是使用生成静态页面；另外一个是优化我们的代码以减少不必要的资源浪费：(

一、不要经常使用new对象，对于整个应用程序中只需要存在一个实例的类，要使用StringBuffer或StringBuilder，对StringBuilder,StringBuilder,StringBuilder，通过静态方法访问单个类。

不要使用诸如Exception可以控制方法推出等错误的方法，但Exception要保持stacktrace消耗性能，除非必要时不使用instanceof进行条件判断，并尽量使用比率的条件判断.在JAVA中使用效率高的类，例如ArrayList，它比Vector更好。

高并发-需要解决的问题

应用缓存

HTTP缓存

多级缓存

池化

异步并发

扩容

队列