微服务基本概念
微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务。
单体架构
单体架构下，所有的功能被打包在一个包里，基本没有外部依赖，部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了服务运行的所有逻辑。
单体架构的特征
应用程序的功能集中化，各个功能模块紧耦合，牵一发而动全身，任何一个功能模块的故障都可能造成整个应用的瘫痪，并且当某个功能模块需要升级时，既需要针对整个应用做开发升级，同时在部署时，需要将旧的应用系统下线，然后将升级的业务系统重新部署，周期长效率低，如果要做灰度发布，快速的迭代升级，单体架构的效率往往是无法满足业务快速迭代更新的需求，因此提出了微服务的架构。
微服务架构：
微服务是一个新兴的软件架构，就是把一个大型的单个应用程序和服务拆分为数十个的支持微服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上，微服务也指一种松耦合的、有一定的有界上下文的面向服务架构。可以让工作变得更为简便，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议，系统中的各个微服务可被独立部署，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些微服务通常基于业务能力构建，并能够通过自动化部署机制来独立部署，各个微服务之间是松耦合的，每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径。
单体架构特征：
开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断；
代码维护难：代码功能耦合在一起，新人不知道何从下手；部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长；
稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉；
扩展性不够：无法满足高并发情况下的业务需求；
微服务架构
易开发：服务粒度更小，而每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情；
易且快的代码更新：当开发者对一个传统的单体应用程序进行变更时，他们必须做详细的QA测试，以确保变更不会影响其他特性或功能。但有了微服务，开发者可以更新应用程序的单个组件，而不会影响其他的部分。测试微服务应用程序仍然是必需的，但它更容易识别和隔离问题，从而加快开发速度并支持DevOps和持续应用程序开发。
独立部署：每个服务能够独立被部署并运行在一个进程内，这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
独立团队和自治：团队对服务的整个生命周期负责，工作在独立的上下文中，自己决策自己治理，而不需要统一的指挥中心，团队和团队之间通过松散的社区部落进行衔接。资源利用率更高：往往比传统的应用程序更有效地利用计算资源，这是因为它们通过扩展组件来处理功能瓶颈问题，这样一来，开发人员只需要为额外的组件部署计算资源，而不需要部署一个完整的应用程序的全新迭代，最终的结果是有更多的资源可以提供给其它任务。
微服务设计原则：
前后端分离：为了更好的支撑微服务架构，微服务在设计时要保证前后端分离，这里的分离是前端和后端的代码分离也就是技术上做分离，最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。
无状态服务：这里的无状态服务指的是将有状态的业务服务改变为无状态的计算类服务。
Rest通讯风格：无状态服务之间进行API通讯的通讯风格。
uploading-image-93345.png
分离模式的方式有几个好处
前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。
分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。
前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的web UI移动App等访问。
无状态服务
对于无状态服务，首先解释一下什么是状态
如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。
那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。
场景说明：
我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点，迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。
Rest 通信风格
Restful 是一种无状态服务之间的通信风格，它的优点是：无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密时，有现成的成熟方案HTTPS可用。
JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
语言无关，各大热门语言都提供成熟的Restful API框架，相对其他的一些RPC框架生态更完善。
当然在有些特殊业务场景下，也需要采用其他的RPC框架，如thrift、avro-rpc、grpc，但绝大多数情况下Restful就足够用了。
腾讯云微服务特征
针对不同行业与使用场景，微服务解决方案包括微服务和微计算两大方案，帮助企业实现低成本地实现系统微服务化，优化系统架构，实现业务的快速迭代。比如，提供了成熟的金融行业微服务化方案和成熟的电商行业微服务化方案。
腾讯云微服务的优势体现
微服务方案：
一站式平台：提供了一站式微服务治理平台，打通微服务API 网关、消息队列等；
全方位管控：全应用生命周期管理，轻松部署，快速发布，立体化监控；微计算方案：快捷高效的配置：无需服务器管理，免除运维、操作系统及软件维护；
合理低廉的价格：价格低廉，根据实际资源进行配置，并只按实际使用付费；
腾讯云微服务产品
腾讯云微服务两大方案用到的产品有
无服务器函数SCF，容器服务CCS，腾讯分布式服务框架TSF，API网关，消息队列CMQ。其中微服务方案用到的产品有TSF、CMQ、CCS和API网关；微计算方案用到的产品有SCF、API网关、CCS等：无服务器云函数（Serverless Cloud Function，SCF）：腾讯云为企业和开发者们提供的无服务器执行环境，帮助您在无需购买和管理服务器的情况下运行代码。
腾讯云容器服务（Cloud Container Service，CCS）：
基于原生kubernetes提供以容器为核心的、高度可扩展的高性能容器管理服务。腾讯分布式服务框架TSF (Tencent Distributed Service Framework) ：一个围绕应用和微服务的PaaS 平台，提供服务全生命周期管理能力和数据化运营支持，提供多维度应用、服务、机器的监控数据，助力服务性能优化；拥抱Spring Cloud 开源社区。
API 网关（API Gateway）：
API 托管服务，提供API 的完整生命周期管理，包括创建、维护、发布、运行、下线等。
消息队列（Message Queue，简称MQ）：是一项高可用、高并发、高可扩展、低延时的分布式消息队列服务，解耦消息的生产与消费，多进程可以同时读写、互不干扰，为企业级架构的核心产品之一。
腾讯云微服务解耦产品使用描述：
腾讯云分布式服务框架TSF，提供了构建云上微服务的分布式架构平台，基于TSF框架，结合腾讯云容器产品CCS，构建分布式的基础服务层，公共服务层集群和数据接入层。TSF框架还提供了不同服务层次间数据消息总线（比如CMQ）的接入，腾讯云中间件服务的接入，提供全局配置服务功能，服务注册发现功能，应用的生命周期管理能力，以及与无服务器函数SCF对接从而实现高效计算能力。而对TSF框架中服务的访问，可以使用API网关作为统一的标准化管理入口，将来自不同终端或第三方平台的请求进行统一化认证、接入等，同时API网关也可以统一封装TSF框架中不同微服务的REST API接口，进行统一鉴权，统一监控。