微服务

㈠ 微服务有哪些特点

相比于传统集中式的应用系统，微服务的优点：

• 每个服务独立存在，所以可以单独部署，不用每次发布某个功能都经历一次全服务发布。

• 遵循单一功能原则，服务之间可以通过RESTFUL或者RPC调用，功能解藕

• “细粒度” 的高可扩展性，每个服务都可以单独扩展，单独负载均衡

• 去中心化，尽可能地实现 “自服务”

• 有利于简化单独的开发测试以及部署，对开发团队友好

微服务缺点：

• 服务的可用性和维护性高度依赖于服务治理，如果治理得不好将会是灾难

• 某些服务可能造成性能瓶颈，某些服务的宕机可能导致很多服务受影响

• 服务配置繁琐

㈡ 什么是微服务

微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

㈢ 微服务,一个服务会影响整个系统吗

摘要： 最近大家都在谈微服务，随着越来越多的在线业务需要提供更大并发的scale-up 和 scale out能力，微服务确实提供了比较好分布式服务的解决方案。

阿里云高级解决方案架构师 杨旭

世界最大混合云的总架构师，4年前，开始作为双11阿里云技术负责人，负责搭建全球最大的混合云结构，把 “双11”的电商业务和技术场景在阿里云上实现，并保障这个混合云在双11当天能够满足全球客户的购物需求。

正文：

最近大家都在谈微服务，随着越来越多的在线业务需要提供更大并发的scale-up 和 scale out能力，微服务确实提供了比较好分布式服务的解决方案。

微服务并不陌生，知道SOA其实也就很容易理解微服务，可以把微服务当做去除了ESB的SOA。ESB是SOA企业服务架构中的总线，而微服务是去中心化的分布式软件架构，个人认为最大的设计区别在于设计初衷：

SOA是为了最大化的实现复杂系统代码的可复用性
而微服务是为了最大限度的解耦，不同业务系统甚至可以是不同语言之间的通信
没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑。所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。

网上的一张图很经典，总结的非常好：

整个系统进化分为三个阶段：

x轴，水平扩展阶段，通过负载均衡服务器不断的横向扩充应用服务器，水平扩展最重要的问题是需要注意不用服务器之间的如何保持session和会话同步，不能让用户在不通服务器之间切换时有感知应用扩展后自然遇到的问题就是DB的瓶颈：连接数，iops等。

z轴，就是对数据库的拆分，难度上了一个台阶，Sharding的基本思想就要把一个数据库如何进行切分，可以分为水平切分和垂直切分，水平切分相对简单，一主多从，多主都可以，根据业务的需要，多主切分设计时需要注意主键的关系，解决多写在进行数据同步时候的冲突问题，垂直拆分更加复杂，一般都会涉及到架构逻辑的改造，需要引入中间件，来进行数据源的管理，垂直拆分时把关系紧密（比如同一模块）的表切分出来放在一个库上，或者通过hash进行拆分，从而将原有数据库切分成类似矩阵一样可以无限扩充的队列。

y轴扩展，最后就是功能分解了，也就是我们讲的微服务切分。微服务拆分将巨型应用按照功能模块分解为一组组不同的服务，淘宝的系统当年也经历了这样的过程，通过五彩石项目从单一的war包拆分成了今天的大家看到买家，卖家中心，交易等系统。

引入微服务前你要知道的两三事：

1、成本升高，引入微服务架构，需要对原来单一系统进行拆分，1到100以后多服务的部署会带来成本的升高

2、解决分布式事务一致性问题

以前单一的系统好处很多，一条sql解决完成所有业务逻辑，微服务做完一件事情需要涉及多系统调用，系统间网络的不确定性给结果带来很多不确定性，如今天淘宝的系统，完成一次交易下单需要在上百个系统之间调用，如何保证系统的可靠性，以及核心数据如钱的最终一致性是设计之初就要想明白的，这里大多都要借助中间件来实现。

3、微服务的逻辑设计原则

随着不断拆分微服务，以及业务的迭代发展，系统之间极有可能出现混乱调用，所以微服务的顶层设计显得尤为重要，架构师需要搞清楚微服务的架构模型。那核心的设计思想就在于如何进行服务的分层，以及服务的重用，通过分层将服务进行分配，上层服务包装下层服务，下层服务负责原子性的操作，上层服务对下层服务进行业务性的组合编排，一定要理解业务，微服务拆分不是简单的系统组合，再说一遍一定要理解业务，否则上层服务一定会出现大量的交叉调用，系统复杂度会指数级上升，好的微服务架构师一定是业务架构师，基于业务的建瓴，微服务设计三部曲，遵循自下而上的设计原则：

原子服务

首先确认最基本业务最维度的原子服务，原子服务定义就是大家都会最大化重用的功能，需要在应用内的闭环操作，没有任何跨其他服务的分支逻辑，杜绝对其他服务的调用，有自己独立的数据存储，作为最底层服务抽象存在，以淘宝为例，卖家数据，卖家数据，订单数据就属于最基本的原子服务。

服务组合

在业务场景下，一个功能都需要跨越多个原子服务来完成一个动作。组合服务就是将业务逻辑抽象拆成独立自主的域，域之间需要保持隔离，服务组合会使用到多个原子服务来完成业务逻辑，如淘宝的交易平台会调用用户，商品，库存等系统。

业务编排

最外层就是面向用户的业务流程，一个产品化的商业流程需要对组合服务进行逻辑编排来完成最终的业务结果，这个编排服务可以完全是自动化的，通过工作流引擎进行组合自动化来完成特定SOP定义，这对企业应用的自动化流程改进也很有意义。如淘宝类目的双十一活动，通过对不通服务组合进行重用实现不通的营销活动逻辑。

4、运维管理的复杂度提升

微服务让应用数量增加很多，链路的集成、测试、部署都成为新的挑战，以前一个war包解决的问题，需要通过多应用发布来完成，发布时服务之间的依赖影响，会导致功能不可用，测试阶段的依赖性可能会让用例跑不下去，这些都会是需要新考虑的问题，需要有平台化的工具来支撑，目前阿里通过aone产品来保证从日常到预发到线上的持续集成交付。

㈣ 微服务的优点

微服务是指提供单个业务功能的服务，从技术角度看就是一种小而独立的处理过程，类似流程概念，能够自行单独启动或销毁，拥有自己独立的数据库。

一个复杂软件架构是由很多这样小而独立运行（有自己的端口）微服务组成，这些独立处理组件之间通讯是通过与语言无关的API进行，简单协议有同步性质的RMI/RPC和 RESTful Web Services，异步的消息推送和Reactive方式。

这些模块化的方式能够使得公司将项目分解分散到多个开发团队，跨不同业务部门，提供非常充分的灵活性，帮助提高项目的生命周期，加快项目开发完成效率。

每个微服务组件都有自己分配的存储 内存和CPU资源，这就使得硬件利用更加易于优化和跟踪，特别是在基于云的Pass环境，开发团队可以使用他们喜欢的技术，任何语言都可以，只要确保微服务之间是可交互的，能够最终组合起最后的应用。

当管理复杂性会因为采取微服务架构而降低，通常更新其中一个微服务组件不会引起连锁反应，因为微服务之间是松耦合的。

目前使用微服务的企业有：Netflix Twitter Amazon Web Services (AWS), Google, eBay等。

因为有很多应用和服务部署在基于云主机的环境中，微服务架构将会严重依赖容器技术，容器隔离了微服务处理过程，将一个应用切分为一个个小的实例，这些容器中的小实例有自己的端口和虚拟化环境。

广泛使用的容器技术是Docker, 一种基于Linux的开源实现，由很多软件公司支持如 Canonical, Red Hat,和Parallels. PaaS服务支持包括Google App Engine, Red Hat Open Shift,和VMware的 Cloud Foundry,。

㈤ 微服务都是用在什么地方能否举例说明一下

随着移动互联网的发展和应用云化的普及，微服务已经成为企业应用服务化架构最流行的设计理念。以微服务、容器、DevOps等为支撑的云原生设计理念，缓解了随着新需求的不断增加，大型单体式应用变更越来越困难的现状，与移动互联网时代下对企业IT架构高效稳定、敏捷响应的要求之间的矛盾。
“Nebulogy纳比云”提供完整的微服务实施平台及赋能工具，加速微服务应用开发和DevOps持续交付，为云应用的构建和运行支撑提供有力的支持。微服务实施方案

㈥ “微服务”是什么意思

微服务是对于微信公众平台帐号提供的辅助管理平台，强化了微信公众号的互动营销推广与客户关系维护功能。

㈦ 什么是微服务框架

不太确定你说的什么是微服务框架，好像来说就是一个小程序的意思吧。

㈧ 微服务优点

微服务是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块为基础，利用模组化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的 API（例如 REST）集相互通讯，且每个服务可以被单独部署，在微服务软件架构风格概念被提出来的初期，它具备以下三个核心特点：

1. 微服务为大型系统而生。 通常我们在系统架构设计上面临的问题都与系统的大小相关，随着业务的快速增长，会带来系统流量压力和复杂度的上升，系统的可维护性和可扩展性成为架构设计的主要考虑因素，微服务架构设计理念通过小而美的业务拆分，通过分而自治来实现复杂系统的优雅设计实现。

2. 微服务架构是面向结果的。 微服务架构设计风格的产生并非是出于学术或为标准而标准的设计，而是在软件架构设计领域不断演进过程中，面对实际工业界所遇到问题，而出现的面向解决实际问题的架构设计风格。

3. 专注于服务的可替代性来设计。 微服务架构设计风格核心要解决的问题之一便是如何便利地在大型系统中进行系统组件的维护和替换，且不影响整体系统稳定性。微服务带来的好处
独立的可扩展性，每个微服务都可以独立进行横向或纵向扩展，根据业务实际增长情况来进行快速扩展；

独立的可升级性，每个微服务都可以独立进行服务升级、更新，不用依赖于其它服务，结合持续集成工具可以进行持续发布，开发人员就可以独立快速完成服务升级发布流程；

易维护性，每个微服务的代码均只专注于完成该单个业务范畴的事情，因此微服务项目代码数量将减少至IDE可以快速加载的大小，这样可以提高了代码的可读性，进而可以提高研发人员的生产效率；

语言无关性，研发人员可以选用自己最为熟悉的语言和框架来完成他们的微服务项目（当然，一般根据每个公司的实际技术栈需要来了），这样在面对新技术或新框架的选用时，微服务能够更好地进行快速响应；

故障和资源的隔离性，在系统中出现不好的资源操作行为时，例如内存泄露、数据库连接未关闭等情况，将仅仅只会影响单个微服务；

优化跨团队沟通，如果要完全实践微服务架构设计风格，研发团队势必会按照新的原则来进行划分，由之前的按照技能、职能划分的方式变为按照业务（单个微服务）来进行划分，如此这般团队里将有各个方向技能的研发人员，沟通效率上来说要优于之前按照技能进行划分的组织架构；

原生基于“云”的系统架构设计，基于微服务架构设计风格，我们能构建出来原生对于“云”具备超高友好度的系统，与常用容器工具如Docker能够很方便地结合，构建持续发布系统与IaaS、PaaS平台对接，使其能够方便的部署于各类“云”上，如公用云、私有云以及混合云。

㈨ SOA和微服务架构的区别

SOA与微服务架构，在架构划分、技术平台选择等方面，均存在一定的区别。

一、架构划分不同

1、SOA强调按水平架构划分为：前、后端、数据库、测试等；

2、微服务强调按垂直架构划分，按业务能力划分，每个服务完成一种特定的功能，服务即产品。

二、技术平台选择不同

1、SOA应用倾向于使用统一的技术平台来解决所有问题；

2、微服务可以针对不同业务特征选择不同技术平台，去中心统一化，发挥各种技术平台的特长。

三、系统间边界处理机制不同

1、SOA架构强调的是异构系统之间的通信和解耦合；（一种粗粒度、松耦合的服务架构）；

2、微服务架构强调的是系统按业务边界做细粒度的拆分和部署。

四、主要目标不同

1、SOA架构，主要目标是确保应用能够交互操作；

2、微服务架构，主要目标是实现新功能、并可以快速拓展开发团队。

参考资料

网络-SOA

网络-微服务架构