Spring Cloud学习笔记之微服务架构

[TOC] ###什么是微服务

    微服务构架方法是以开发一种小型服务的方式，来开发一个独立的应用系统的。     其中每一个小型服务都运行在本身的进程中，并常常采用HTTP资源API这样轻量的机制来相互通讯。     这些服务围绕业务功能进行构建，并能经过全自动的部署机制来进行独立部署。     这些微服务可使用不一样的语言来编写，而且可使用不一样的数据存储技术。     对这些微服务咱们仅作最低限度的集中管理。

###架构优势 ####1. 易于开发和维护     一个微服务只关注一个特定的业务功能。因此它的业务清晰，代码量较少。开发和维护单个微服务相对是比较简单的，而整个应用是由若干个微服务构建而成的，因此整个应用也会维持在可控状态。 ####2. 单个微服务启动较快     单个微服务代码量较少，因此启动会比较快 ####3. 局部修改容易部署     单体应用只要有修改，就得从新部署整个应用，微服务解决了这样的问题。通常来说，对某个微服务进行修改，只须要部署这个服务便可。 ####4. 技术栈不受限     在微服务中，咱们能够结合项目业务及团队的特色，合理选择技术栈。例如某些服务可以使用关系型数据库，某些应用有图形计算的需求，可使用Neo4j,某些应用服务有并发需求，能够采用内存数据库(redis、couchbase);甚至能够根据须要，部分微服务使用JAVA开发，部分微服务使用NodeJS进行开发。 ####5. 按需伸缩     咱们能够根据需求，实践细粒度的扩展。例如，系统中某个微服务遇到了瓶颈。咱们能够结合这个微服务的业务特色，增长内存，升级CPU或者增长节点。 ###架构的挑战 ####1. 运维要求较高     更多的服务意味着更多的运维投入。在单体架构中，只须要保证一个应用的正常运行；而在微服务中，须要保证几十个乃至几百个服务的正常运行与协做。 ####2. 分布式固有的复杂性     使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都给咱们带来了很大的挑战。 ####3. 接口调整成本高     微服务之间经过接口进行通讯。若是修改某一个微服务的API。可能全部使用了该接口的微服务都须要作调整。 ####4. 重复劳动     不少服务可能都会使用到相同的功能。再这个功能并无达到分解为一个微服务的程序，这个时候，可能各个服务都会开发这一功能，从而致使代码重复。 ###设计原则     微服务有优势，也有缺点，咱们须要拈轻怕重,因此在实践中，须要遵照一些原则。 ####1. 单一职责原则     高内聚，低耦合     遵照单一职责原则，将不一样的职责封装到不一样的类或模块中 ####2. 服务自治原则     每一个服务应当具有独立的业务能力，依赖与运行环境 ####3. 轻量级通讯原则 ####4. 接口明确原则     每一个服务的对外接口应该明肯定义，并尽可能保持不变

Spring Cloud: http://projects.spring.io/spring-cloud/

GitHub: https://github.com/spring-cloud/