什么是微服务？ - 简书
什么是微服务？
一、背景介绍：传统的it架构的缺陷：使用传统的整体式架构(Monolithic Architecture)应用开发系统，如CRM、ERP等大型应用，随着新需求的不断增加，企业更新和修复大型整体式应用变得越来越困难；随着移动互联网的发展，企业被迫将其应用迁移至现代化UI界面架构以便能兼容移动设备，这要求企业能实现应用功能的快速上线；许多企业在SOA投资中得到的回报有限，SOA可以通过标准化服务接口实现能力的重用，但对于快速变化的需求，受到整体式应用的限制，有时候显得力不从心；二、什么是微服务？微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。三、微服务中的spring-cloudSpring Cloud是一个相对比较新的微服务框架，2016n年推出1.0的release版本. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，控制总线，一次性token，全居琐，leader选举，分布式session，集群状态）中快速构建的工具，使用Spring Cloud的开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。三、什么是Eureak？Eureak的结构特点1. 是纯正的 servlet 应用，需构建成war包部署2. 使用了 Jersey 框架实现自身的 RESTful HTTP接口3. peer之间的同步与服务的注册全部通过 HTTP 协议实现4. 定时任务(发送心跳、定时清理过期服务、节点同步等)通过 JDK 自带的 Timer 实现5. 内存缓存使用Google的guava包实现四、实战
项目结构如下
首先创建moduel
moudel里面创建服务：
配置application.yml
完成运行DemoApplication启动服务结果如图：
界面如下，Application为空说明没有注册service。接下来我们编写service-client同样创建model
编写配置文件：
使用简单controller编写，告诉这个是Client端
启动服务启动成功界面如图：
查看我们的server：
这里已经注册了我们的服务。说明服务的注册与获取成功了。
接下来使用ribbon+restTemplate实现负载均衡：复制一个client，然后修改端口。
方便等会测试负载均衡创建moduel-ribbon
结构如上首先配置application.yml
然后在application里面加载实现负载均衡的RestTemplate
编写service和controller实现调用负载均衡
完成编写，启动8632的service，启动ribbon，使用http:localhost:8634/lzn?name=lzn调用，刷新发现结果为端口服务调用平均。这只是一个简单Eureka的调用。cloud有很多我们需要的可以学习的服务。
Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。他们将在任何分布式...
什么是微服务？微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一...
上次写了一篇文章叫Spring Cloud在国内中小型公司能用起来吗?介绍了Spring Cloud是否能在中小公司使用起来，这篇文章是它的姊妹篇。其实我们在这条路上已经走了一年多，从16年初到现在。在使用Spring Cloud之前我们对微服务实践是没有太多的体会和经验的...
软件是有生命的，你做出来的架构决定了这个软件它这一生是坎坷还是幸福。 本文不是讲解如何使用Spring Cloud的教程，而是探讨Spring Cloud是什么，以及它诞生的背景和意义。 1 背景 2008年以后，国内互联网行业飞速发展，我们对软件系统的需求已经不再是过去”...
一.应用系统的架构历史 二.什么是微服务？ 2.1 微服务概述 起源:微服务的概念源于 2014 年 3 月 Martin Fowler 所写的一篇文章“Microservices”。文中内容提到：微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互...
前三点对歌词三个小节进行总体的情感把握 1，艰辛的焦虑。安宁的盼望。动荡的绝望。 2，等待自由的迷茫。付出情感的纠结。 3，木然在世的孤独。对沧海桑田的麻木。 对歌词的三个小节透露出的情感进行归纳，即: 4，于是，归纳一下: a.焦虑的生存状态。 b.抱有对安宁的渴望。 c...
今天，也许是因为感冒，心情不佳。上班也了无激情。心里很想说，为什么我对这个班的学生没有激情呢？以前，我在牛佛的那个四年级，我总对他们有一种充满信心，充满希望的感觉。记得，我在跟校长说我这个班情况的时候，就是表达的，他们未来一定是非常有出息的孩子，他们是有希望的孩子。但，为...
过渡原来如此（继目录页后的过渡页） 建议大家在看这篇教程时，先去看看燕燕老师前面发表的那两篇教程，这样大家就更清楚了ppt的制作步骤了，因为接下来的这篇教程可以说是ppt制作中最最简单的一页了。 看到上面的图片没，当大家有了目录页之后，大家就可以制作过渡页了，那什么是过渡页...
两幅字画，一本著作，业已收到。感激之余，不由想起当年老师的翩翩风度：一本《简爱》置于讲桌，于是深入浅出，旁征博引，纵横捭阖，挥洒自如，不拘泥教材，不追捧考试。老师曾留下许多经典名言：“艺术都是相通的”，“艺术是需要沉淀的”，“黾勉务事，彻底做人”。不知道是抨击时弊还是讲某个...
标题是借用的，取自于英国谍报史家迪肯的同名著作。 小时候，家里的书极少，所看的书自然就不多，所以对能看到的不多的书都是看了又看，看得最多的是平托上校的《我的反间谍生涯》，再有就是胡绳的《从鸦片战争到五四运动》，另外还有不是书的书，是父亲从报纸上剪下来装订在一起的薄薄三册沈醉...微服务——程序员的自我修养
发表于 13:28|
摘要：微服务在2016年成为仅次于物联网和认知计算的第三热门技术，微服务究竟有何等神通，让ThoughtWorks、Netflix、Amazon、Uber等公司趋之若鹜？
微服务在2016年成为仅次于物联网和认知计算的第三热门技术，微服务究竟有何等神通，让ThoughtWorks、Netflix、Amazon、Uber等公司趋之若鹜？
传统应用之殇
版本发布&千年等一回 在过去传统企业应用开发模式下，每当遇到需求要修改时，不得不按照大颗粒系统发布版本，瀑布式的版本计划困住了程序员那优雅的双手。
应用升级&祝你平安 应用无法做到永远在线，大版本升级时，不得不停机中断服务。一个小小的问题就有可能带来整个系统的崩溃。
技术选型&独角戏 技术实现单一，需要想办法用一种技术解决所有问题。每个问题都变成钉子，每个方案都被当成锤子。
微服务&初见
如何解决传统应用开发模式逐渐暴露出来的牢骚？随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队等实践的流行，微服务架构逐渐地被广大勤劳智慧的架构师们归纳总结而出：
微服务架构风格，描述的是一个大型复杂软件应用系统由若干个微服务组成。系统中的各个微服务能被独立部署和扩展，每个微服务还能提供一个稳固的模块边界。各个微服务之间是松耦合的，微服务很小，专注于做好一件事情。微服务框架带了良好的技术异构性、弹性、扩展性，它的简化部署为持续交付提供了巨大推动力。
微服务&爱你在心口难开&&& &&&&&&&&&&&&&&&
事实是大量传统应用在微服务改造过程并没有想象的那么顺滑，虽然微服务带来的好处多多，同时也引入了很多新的挑战，如：
l分布式编程难度更大，远程调用更慢且总存在失败的风险
l对分布式系统来说，保持一致性非常困难，意味大家都要处理最终一致性
l需要一个成熟的团队（机制）来管理大量需要频繁部署的服务
那么，是否该用微服务架构？什么时候用微服务架构？该用什么样的微服务架构？怎么用微服务架构？遗留业务如何快速迁移上云？微服务化之后繁杂的微服务如何管理运维？
微服务&多了&引擎&两个字
如何解决以上问题？
你也许希望有一个开发框架，能够帮助各企业和开发者最大化的降低应用微服务化的门槛。
你也许希望有一些工具，能够有力支撑企业在微服务架构下的高效开发。
你也许希望有一个平台，能够帮助企业和开发者全方位管理改造后的大量微服务。
你也许希望有一位领先微服务改造专家，能够给予专业的微服务化解决方案指导。
微服务引擎CSE是全新的企业级微服务开发与管理平台，包含了微服务SDK、一系列配套的开发工具以及一站式微服务应用管理平台，致力于为企业提供0门槛服务化改造，为企业提供微服务全生命周期管理服务。在CSE上线之前先让我们露出一小部分核心性感的特性刷新你的微服务观。
1.开放是一种人生境界
CSE支持多开发模式多语言多协议，传统应用改造0门槛。无论遗留应用是SpringMVC、透明代理、亦或是JAX-RS的开发模式，业务代码0改动就可以完成微服务改造。无论你是倾心GO语言还是青睐JAVA，无论你是执着REST协议还是钟情RPC，没有做不到，只有你想不到。同时，CSE-SDK还兼容spring-cloud主流社区，保持与业界生态能力互通。
2.用一杯咖啡的时间完成微服务改造
CSE黑科技助力传统应用0修改服务化。当然开发者可能已经写好了一些微服务或者真的一丁点儿都不想改动遗留代码。CSE提供了一项黑科技，支持非侵入接入微服务治理。给你一个微服务摇篮，让遗留应用无缝接入CSE微服务治理与管控平台，让你的应用安全可靠舒心。
3.周末再也不想接到加班电话？
一站式微服务应用管理云服务，服务论剑随时随地：在微服务开发完毕之后，繁杂的微服务实例如何管理、如何监控、如何运维？微服务引擎的一站式微服务应用管理平台，提供微服务全生命周期管理，提供微服务治理、微服务安全管理、灰度发布、分布式事务等等特性。让你享受谈笑间樯橹灰飞烟灭的商业快感！
10月31日，微服务引擎即将震撼上线，预知更多精彩预告请访问华为云社区：
PS：我们还有专业的微服务解决方案团队，提供一站式解决方案支持哦！
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章一、首先谈谈传统系统架构和微服务架构
传统的系统架构是单一架构模式。这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包。
微服务架构则是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。
二、为什么需要微服务架构？
单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。可是当应用随着时间的推进，加入的功能越来越多，最终会变得巨大，一个项目中很有可能数百万行的代码，互相之间繁琐的jar包。
1、&&& 不再适用敏捷开发，过于复杂，任何开发者都不能够完全理解，修复漏洞和实现新功能变得困难和耗时。
2、&&& 规模越大，启动时间越长，自然会拖慢开发进度，一个小功能的修改部署起来变得困难，必须重新部署整个应用。
3、&&& 系统的不同的模块的需要不同的特定的虚拟机环境时，由于是整体应用，那么只能折中选择。
4、&&& 任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性
5、&&& 还有一个如果想整体应用采用新的技术，新的框架或者语言，那是不可能的。
如果采用微服务架构模式，则可以解决单一架构模式带来的系统复杂性。主要包括以下几个好处：
1、&&& 由于每个服务都是独立并且微小的，由单独的团队负责，仍然可以采用敏捷开发模式，自由的选择合适的技术，甚至可以重写老服务，当然都要遵守统一的API约定。
2、&&& 每一个微服务都是独立部署的，可以进行快速迭代部署，根据各自服务需求选择合适的虚拟机和使用最匹配的服务资源要求的硬件。
3、&&& 整体应用程序被分解成可管理的模块和服务，单个的服务可以更快的开发、更简单的理解和维护。
4、&&& 一些需要进行负载均衡的服务可以部署在多个云虚拟机上，加入NGINX这样的负载均衡器在多个实例之间分发请求，这样不需要整个应用进行负载均衡了。
每个后端服务暴露一套REST API，大部分服务调用其他服务提供的API。每个服务都有自己的数据库模式，而不是共享单个数据库模式。尽管这会造成某些数据的冗余，但是对于微服务架构这个独立数据库模式是必要的，确保了独立服务之间的松散耦合。
以上介绍的微服务架构模式表面上类似于SOA，两种架构都包含一组服务。可以认为微服务架构是不包括Web服务规范（WS-）、企业服务总线（ESB）的SOA。基于微服务的应用倾向于使用更简单轻量级的协议，比如 REST 而不是 WS-。微服务自己实现类似 ESB 的功能并且拒绝 SOA 的其他部分，比如规范模式的概念。
三、不可否认的微服务缺点
1、& 微服务应用作为分布式系统带来了复杂性。当应用是整体应用程序时，模块之间调用都在应用之内，即使进行分布式部署，依然在应用内调用。可是微服务是多个独立的服务，当进行模块调用的时候，分布式将会麻烦。
2、& 多个独立数据库，事务的实现更具挑战性。
3、& 测试微服务变得复杂，当一个服务依赖另外一个服务时，测试时候需要另外一个服务的支持。
4、& 部署基于微服务的应用也很复杂，整体应用程序部署只需要部署在一组相同的服务器上，在这些服务前面加入传统的负载均衡器即可。独立服务的不是讲变得复杂，需要更高的自动化形式。
总结：以上就是微服务的基础介绍，那么如何实现微服务架构，Spring Cloud将起到什么作用，敬请期待。
最后推荐学习微服务的相关基础知识:
PS:刚开始写博客，不定期更新，记录学习Spring Cloud的学习过程
阅读(...) 评论()【图片】资深女程序员告诉你：微服务架构如何实践？80%以上男程序员点赞【康视宝吧】_百度贴吧
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&签到排名：今日本吧第个签到，本吧因你更精彩，明天继续来努力！
本吧签到人数：0成为超级会员，使用一键签到本月漏签0次！成为超级会员，赠送8张补签卡连续签到：天&&累计签到：天超级会员单次开通12个月以上，赠送连续签到卡3张
关注：66贴子：
资深女程序员告诉你：微服务架构如何实践？80%以上男程序员点赞收藏
上篇文章给大家介绍了什么是微服务架构，本文将会讲到如何实践微服务。 不知道微服务架构的，可以看我上一篇文章听上去好像都不错，具体怎么落地啊？这需要回答下面几个问题：客户端如何访问这些服务？服务之间如何通信？这么多服务，怎么找?服务挂了怎么办？客户端如何访问这些服务？原来的Monolithic方式开发，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的？后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们 拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无 状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，他的作用包括提供统一服务入口，让微服务对前台透明聚合后台的服务，节省流量，提升性能提供安全，过滤，流控等API管理功能我的理解其实这个API Gateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作 用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。一般用过Taobao Open Platform的就能很容易的体会，TAO就是这个API Gateway。给大家分享一个java学习交流群： 进群邀请码（编号）：寂静群内不定时分享干货，包括2017最新的java企业案例学习资料和零基础入门教程，欢迎初学和进阶中的小伙伴入群学习交流服务之间如何通信？因为所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通行就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式。这几种方式，展开来讲都可以写本书，而且大家一般都比较熟悉细节了， 就不展开讲了。同步调用REST（JAX-RS，Spring Boot）RPC（Thrift, Dubbo）异步消息调用(Kafka, Notify, MetaQ)一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要 求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个 的开发规范和统一的服务框架时，他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能 保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。这么多服务，怎么找?在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互 感知？服务如何管理？这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当 服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法， 找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。这么多服务，服务挂了怎么办？前面提到，Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠 的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。我们刚遇到一个线上故障就是一个很不起眼的SQL计数功能，在访问量上升 时，导致数据库load彪高，影响了所在应用的性能，从而影响所有调用这个应用服务的前台应用。所以当我们的系统是由一系列的服务调用链组成的时候，我们 必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：重试机制限流熔断机制负载均衡降级（本地缓存）这些方法基本上都很明确通用，就不详细说明了。比如Netflix的Hystrix：https://github.com/Netflix/HystrixWHY - 微服务的应用这里有一个图非常好的总结微服务架构需要考虑的问题，包括API Gateway服务间调用服务发现服务容错服务部署数据调用微服务的优点和缺点（或者说挑战）一样明显。优点开发简单技术栈灵活服务独立无依赖独立按需扩展可用性高缺点（挑战）多服务运维难度系统部署依赖服务间通信成本数据一致性系统集成测试重复工作性能监控没有最好的，只有适合自己的。对于大的互联网公司，微服务架构是血液，是习惯，每家公司都有自己的套路和架构，细节有不同，但是核心理念是通的。对于一般的公司而言，实践微服务有非常大的技术挑战，于是乎才有了这么多IT供应商考虑这里的商机。微服务比较适合未来有一定的扩展复杂度，且有 很大用户增量预期的应用，说人话就是新兴的互联网公司。创业初期，不可能买大量的机器或者很贵的机器，但是又必须考虑应对成功后的巨量的用户，微服务架构 成了最好的选择。So What - 思考看到上面的图，不是不觉得特别的熟悉？其实我们N年前就用的滚瓜烂熟了好不好？裤子都拖了，你就给我看这个？其实本来所谓的微服务就是对互联网在应用技术的一个总结归纳，IT厂商鼓吹所有概念无非是为了生意（business），SOA是，Cloud是，Microservice也是。下面玩笑很有意思的概括了这个情况（我加了第一条线，原图见这里）所以微服对我们的思考我觉得更多的是思维上的，对已微服务架构， 技术上不是问题，意识比工具重要。按照业务 或者客户需求组织资源（这是最难的）做有生命的产品，而不是项目头狼战队，全栈化后台服务贯彻Single Responsibility PrincipleVM-&Docker （to PE）DevOps (to PE)同时，对于开发同学，有这么多的中间件和强大的PE支持固然是好事，我们也需要深入去了解这些中间件背后的原理，知其然知其所以然，设想下，如果我们是一个小公司的CTO，离开的阿里的大环境，在有限的技术资源如何通过开源技术实施微服务？最后，一般提到微服务都离不开DevOps和Docker，理解微服务架构是核心，devops和docker是工具，是手段。下次在抽时间再学习整理下。
登录百度帐号万事皆因忙中错，好人半自苦中来
微服务架构：理解什么是微服务
1 什么是微服务
微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”(http://martinfowler.com/articles/microservices.html)。
尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等等。 微服务架构的思考是从与整体应用对比而产生的。
2 微服务的一些常见误解
关于一些比较概念的澄清：
在同一范畴内比较才有意义：
微服务架构 vs. SOA – 两者都是架构风格范畴，但其关注领域与涉及范围不同。SOA更关注企业规模范围，微服务架构则更关注应用规模范围。
微服务组件 vs. 服务组件 – 两者都是描述业务功能的具体实现，其区别在于粒度不同，此外还有在可管理性、灵活性上的差异。
概念混淆的不恰当比较
微服务 vs. SOA – 不恰当的比较。微服务是组件范畴，而SOA是一种架构设计风格。因此应该比较的是微服务架构与SOA。
微服务 vs. API – 不恰当的比较。 API是接口，是业务功能暴露的一种机制。微服务架构是用于实施业务功能的组件架构。因此直接比较它们是没有意义的。
微服务 vs. 服务– 不恰当的比较。“服务”在不同的场景下有不同的含义，需要进一步澄清其描述的语境，是指服务实施、服务暴露、服务定义还是其他？微服务亦是如此，需要有特定语境才可判断比较是否有意义。
3一个简单的微服务应用例子：航班预订应用
将航班预订应用划分为预订航班、时间表查询、计算票价、分配座位、管理奖励、更新客户、调整库存七个微服务实施。
4 哪些应用会从微服务收益 ？
记录型系统(System of Record)将从微服务方法中获益最多。例如可将大型应用按相对独立的业务功能分解成若干个微服务实现。
交互型系统(System of Engagement)也将受益于微服务方法，例如渠道应用可以应用“后端服务前端”的模式实现。
分析型系统(System of Insight)则可能对微服务受益不多。其他架构模式如管道及过滤模式可能更适用于分析型系统。
5，微服务架构的优点：
每个服务都比较简单，只关注于一个业务功能。
微服务架构方式是松耦合的，可以提供更高的灵活性。
微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。
每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。
微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。
6 微服务架构的缺点：
微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。
运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由20个微服务组成，可能需要40~60个进程。
必须有坚实的DevOps开发运维一体化技能：开发人员需要熟知运维与投产环境，开发人员也需要掌握必要的数据存储技术如NoSQL，具有较强DevOps技能的人员比较稀缺，会带来招聘人才方面的挑战。
隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。在实际环境中，一个新品发布可能被迫同时发布大量服务，由于集成点的大量增加，微服务架构会有更高的发布风险。
代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。
分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。
异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。
可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。
没有更多推荐了，}