本文为大家介绍了5个迁移到微服务架构所需做的准备步骤，包括如何划分微服务，微服务和组织结构间的误解，如何划分组织架构，以及在实现微服务架构中需要尽早考虑的一些问题，值得大家参考
让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：域名申请、雅安服务器托管、营销软件、网站建设、江都网站维护、网站推广。
时至今日，微服务相关的话题不胜枚举，上百次的会议，在线讨论以及相关文章。你可以假设大家已经认识到其优点以及与之俱来的风险。然而，有很多组织没有事先准备就迈入这个潮流了。自然，这也就导致了在架构实现过程中的失败。
有一位智者曾经说过，“对于商业中所应用的任何技术而言，有2条规则，其一，将自动化应用于高效的运维上才能增加效率；其二，将自动化应用于低效的运维反而会降低效率。”我认为这种哲学对微服务而言亦行之有效。如果你的组织没有为此准备就贸然迁移，很可能会招致失败。以上就是本文的出发点，我将为大家带来在实现微服务架构前需要准备的5个关键步骤。
从绘图入手
在开发特定的微服务时，许多开发者都会犯同一个错误：直接写代码。或许，这可能就是你能够犯的最严重的错误了。诚然，对于一个服务而言，你可能会获得成功，但是随着服务数量的上升，所有事情都会变得一团乱。
和其它产品一样，它也需要被创造，需要以设计作为初始步骤。将团队汇聚到桌子周围，自由地在纸上（或者白板）绘制服务。首先，找出你所构建的应用的main函数。然后，自顶向下地将它分解成最小单元。最后，找出不同单元的互联通性。这些功能将会成为你的微服务。
比如，在一款图书预览应用中，其主要的功能就是比较不同的图书。然而，也有许多其他功能需要开发，例如创建用户履历，评分，评论，图书数据库等。识别每个功能，是将它们转为微服务的关键。
整个过程将会持续超过一天时间，并且需要多次迭代直至完美。当然，你将需要从许多不同部门的人员手中获得输入，以确保能够知晓其视角和观点，并确保你不会遗漏任何系统功能。
微服务并不是组织结构
根据你所在公司的组织结构定义微服务，这似乎是很自然的。如果你正在构建单体（monolithic）应用，这或许真是一个恰当的解决方案。但是，在实现微服务架构时，它可能就是一个错误的决定了。
也许，这对于销售部门或客户服务是可行的，但是许多组织只有一个部门处理所有的数据库。因此，为所有数据库创建一个微服务将会导致单点故障。而没有单点故障，则是微服务的关键特性之一。
你希望通过服务实现的一些功能可能会涉及几个组织部门，或者，你可能将会需要为一个部门构建许多微服务。总结一下，你需要将架构聚焦于你想要提供的服务，而非你们公司的组织结构。
创建合适的组织结构
转变到一个全然不同的组织架构，能够满足公司在管控活动上变化的需要。之前2个步骤关注于应用的设计，以便能够为最终用户提供正确的功能。现在，是时候确保对于新的架构而言，你拥有恰当的运维支持了。
你将不得不放弃原有的部门结构，并使团队关注于某个微服务。这意味着这些团队将由拥有不同技能的成员组成，如系统分析师、UX/UI设计师、后端工程师、前端工程师等。如此一来，团队就能够彻底负责它们的项目（微服务）——从开发部署到运维、监控和管理。反过来，由于团队觉得自己拥有这个产品，因此将提升其创建产品的积极性。
团队的规模视公司/项目的总体人数而定；当然，根据专家的建议，比较理想的规模是每个团队8-10人。和单体架构不同，微服务架构使得你能够根据业务的增长来扩展团队规模。
当然，所有团队将会（需要）积极配合，以最终促成整个项目。这便是这种结构的主要好处，使我们能够尽可能快地向市场交付产品。
性能和可靠性同样重要
切换到微服务架构的整体想法，便是使得创建的最终产品相比于单体应用而言拥有更好的性能，更佳的稳定性（例如，更低的下线风险），同时可以更快地交付市场。
将改进性能作为设计的一部分是很重要的，这将确保潜在问题能够尽早被考虑。通常，（性能）问题都源自微服务设计主要考虑功能。然而，如果在更大的服务下，服务崩溃或者变得很慢，那么它就没什么用了。每个服务应该拥有2-3个替代机制，当下层资源失败时，它便可以继续运作。当其中一个机制无法在可接受时间窗口内响应时，服务也需要做到快速切换。
在前期考虑让服务支持更大的负载变动，你的应用将能够应对实际挑战，你将领先市场，当然这也是你在第一时间考虑切换到微服务的主要原因！
变更先行
忽略应用的变化是不切实际的。开发者一直在增加和移除功能，变更代码，替换应用的核心元素等，这在微服务应用中更甚。更确切地说，微服务就是持续演进的。
当你每天需要处理多次代码升级时，最好接受一个观点：变更是持续的，而非对于稳定状态的一次偶然性中断。一旦你认知到这一点，你将意识到一开始便整合变更的灵活性需求的重要性。确保应用一直正常工作的一种方式便是准备服务API，这样微服务间便可继续通信，即使它们已被改变。另外，你还需要引入版本控制，以允许服务同时开放新旧接口。
另一方面，数据存储的演进是一个更大的挑战。改进数据库模式（schema），使其支持新的功能，传统观点中，这是应用升级时最难处理的部分，微服务并不会使其变得更加简单。然而，单就增加新的域且不破坏现有结构这一点而言，NoSQL数据库会更加灵活。如果你希望你的数据存储需求持续演进（谁不希望呢？），那么你应该将可演化的数据存储作为微服务设计的努力方向之一。
在迁移到微服务架构时，做适当的准备是整个项目成功的关键因素，这一点我们可以认同。只有经过仔细的准备，创新设计思维，并且具备合适的运维和管理结构，你才能收获微服务带来的所有好处！
1.将复杂的业务拆分成多个小的业务,每个业务拆分成一个服务,将复杂的问题简单化。利于分工,降低新人的学习成本。
2.微服务应用的一个最大的优点是,它们往往比传统的应用程序更有效地利用计算资源。这是因为它们通过扩展组件来处理功能瓶颈问题。这样一来,开发人员只需要为额外的组件部署计算资源,而不需要部署一个完整的应用程序的全新迭代。最终的结果是有更多的资源可以提供给其它任务。
3.微服务应用程序的另一个好处是,它们更快且更容易更新。当开发者对一个传统的单体应用程序进行变更时,他们必须做详细的QA测试,以确保变更不会影响其他特性或功能。但有了微服务,开发者可以更新应用程序的单个组件,而不会影响其他的部分。测试微服务应用程序仍然是必需的,但它更容易识别和隔离问题,从而加快开发速度并支持DevOps和持续应用程序开发。
4.微服务架构有助于新兴的云服务,如事件驱动计算。类似AWS Lambda这样的功能让开发人员能够编写代码处于休眠状态,直到应用程序事件触发。事件处理时才需要使用计算资源，而企业只需要为每次事件,而不是固定数目的计算实例支付。
缺点1.整体复杂度更高,微服务根本上说是一个分布式系统。开发者需要选择和实现基于消息或者 RPC 的进程间通信机制。虽然这个有很多框架可供选择,并不需要从头实现。但是整体上的代码复杂度是提高了。
2.微服务架构上每个业务有自己的数据库。以前在单体应用中很好解决的事务问题,现在变得很困难。在基于微服务的应用程序中,需要更新不同服务所用的数据库,通常不会选择分布式事务,不仅仅是因为 CAP 定理。他们根本不支持如今高度可扩展的 NoSQL 数据库和消息代理,最后不得不使用基于最终一致性的方法,这对于开发人员来说更具挑战性。
3.测试微服务应用程序也很复杂。例如,使用 Spring Boot,我只需要编写一个测试类来启动一个单体 web 应用程序并测试其 REST API。相比之下,一个类似的测试类对于微服务来说需要启动该服务及其所依赖的所有服务,或者至少要做服务mock,虽然这不是一件高深的事情,但不要低估了这多出来的工作量和复杂度。
SOA与微服务的区别？
SOA的提出是在企业计算领域，就是要将紧耦合的系统，划分为面向业务的，粗粒度，松耦合，无状态的服务。服务发布出来供其他服务调用，一组互相依赖的服务就构成了SOA架构下的系统。
基于这些基础的服务，可以将业务过程用类似BPEL流程的方式编排起来，而BPEL反映的是业务处理的过程，这些过程对于业务人员更为直观，调整也比hardcode的代码更容易。
当然企业还需要对服务治理，比如服务注册库，监控管理等。
我们知道企业计算领域，如果不是交易系统的话，并发量都不是很大的，所以大多数情况下，一台服务器就容纳将许许多多的服务，这些服务采用统一的基础设施，可能都运行在一个应用服务器的进程中。虽然说是面向服务了，但还是单一的系统。
而微服务架构大体是从互联网企业兴起的，由于大规模用户，对分布式系统的要求很高，如果像企业计算那样的系统，伸缩就需要多个容纳续续多多的服务的系统实例，前面通过负载均衡使得多个系统成为一个集群。但这是很不方便的，互联网企业迭代的周期很短，一周可能发布一个版本，甚至可能每天一个版本，而不同的子系统的发布周期是不一样的。而且，不同的子系统也不像原来企业计算那样采用集中式的存储，使用昂贵的Oracle存储整个系统的数据，二是使用MongoDB，HBase，Cassandra等NOSQL数据库和Redis，memcache等分布式缓存。那么就倾向采用以子系统为分割，不同的子系统采用自己的架构，那么各个服务运行自己的Web容器中，当需要增加计算能力的时候，只需要增加这个子系统或服务的实例就好了，当升级的时候，可以不影响别的子系统。这种组织方式大体上就被称作微服务架构。
微服务与SOA相比，更强调分布式系统的特性，比如横向伸缩性，服务发现，负载均衡，故障转移，高可用。互联网开发对服务治理提出了更多的要求，比如多版本，比如灰度升级，比如服务降级，比如分布式跟踪，这些都是在SOA实践中重视不够的。
Docker容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似Node.js或Spring Boot的技术跑在自己的进程中。可能在几十台计算机中运行成千上万个Docker容器，每个容器都运行着服务的一个实例。随时可以增加某个服务的实例数，或者某个实例崩溃后，在其他的计算机上再创建该服务的新的实例。
如何拆分服务？
要围绕业务模块进行拆分，拆分粒度应该保证微服务具有业务的独立性与完整性，尽可能少的存在服务依赖，链式调用。但是，在实际开发过程中，有的时候单体架构更加适合当前的项目。实际上，微服务的设计并不是一蹴而就的，它是一个设计与反馈过程。因此，我们在设计之初可以将服务的粒度设计的大一些，并考虑其可扩展性，随着业务的发展，进行动态地拆分也是一个不错的选择。
REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资源"（Resources）的"表现层"。
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它，每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地址或独一无二的识别符。
客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词：GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
实际上呢，不是所有的东西都是“资源”，尤其是在业务系统中，缺点如下：
有个接口是更新订单状态，你是用上面的GET POST PUT DELETE 哪个呢，看样子应该是PUT，但是路径呢PUT /tickets/12
我有时候多个接口 ，更新订单收款状态，更新订单支款状态，更新订单结算状态；
Restful 的路径明显不友好不够用；
再比如，批量删除，DELETE还好用么，DELETE /tickets/12 #删除ticekt 12 这种形式如果要传数组怎么办，url是不是不够友好？
再比如，Resuful要求 GET /tickets # 获取ticket列表 。我们曾经有个需求，对方会把不超过1000个订单id传给我们，我们系统过滤其中一部分特殊订单；这也是个查询服务，用GET /tickets # 获取ticket列表的形式，1000个订单id显然是超过GET url长度的，这里也不合适；再者，我想开发多个条件查询列表服务，路径这么浅显然不合适；
实际业务中，我们webapi的路径是这样的：systemAlias/controller/action
总结下规则：
简单查询尽量用GET，好处是可以直接带查询参数copy api路径；
复杂查询和更新用POST，用的最多；
不用PUT和DELETE，原因是增加复杂度，并没有带来什么好处
看看BAT的很多openapi，也是写着restful，实际没有严格遵守，都是get和post，这是也很多人不知道put和delete的原因
如：
//根据订单id获取订单
GET oms/order/queryOrderById?id=value1param2=value2
//根据订单id List获取订单
POST oms/order/queryOrderByIdList
//根据条件查询订单，带分页参数
POST oms/order/queryOrderByCondition
//更新订单收款状态
POST oms/order/updateOrderCollectionStatus
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
//批量更新订单收款状态
POST oms/order/updateOrderCollectionStatusInBatch
//批量删除订单，带操作来源
POST oms/order/deleteOrderInBatch
微服务如何进行数据库管理？
CAP 原理(CAP Theorem)
在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP 原理中，有三个要素：
CAP 原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。
因此在进行分布式架构设计时，必须做出取舍。而对于分布式数据系统，分区容忍性是基本要求 ，否则就失去了价值，因此设计分布式数据系统，就是在一致性和可用性之间取一个平衡。
对于大多数 WEB 应用，其实并不需要强一致性，因此牺牲一致性而换取高可用性，是目前多数分布式数据库产品的方向。
当然，牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。
牺牲一致性，只是不再要求关系型数 据库中的强一致性，而是只要系统能达到最终一致性即可，考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。
通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的，“用户感知到的一致性”的时间窗口则 取决于数据复制到一致状态的时间。
最终一致性(eventually consistent)
对于一致性，可以分为从客户端和服务端两个不同的视角。
从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。
从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。
一致性是因为有并发读写才有的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
从客户端角度，多进程并发访问时，更新过的数据在不同进程如何获取的不同策略，决定了不同的一致性。
对于关系型数据库，要求更新过的数据能被后续的 访问都能看到，这是强一致性 ;如果能容忍后续的部分或者全部访问不到，则是弱一致性 ; 如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。
从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，是提高系统的可用度和用户体验非常重要的方面。
那么问题来了，如何实现数据的最终一致性呢?答案就在事件驱动架构。
最佳解决办法是采用事件驱动架构。其中碰到的一个挑战是如何原子性的更新状态和发布事件。有几种方法可以解决此问题，包括将数据库视为消息队列和事件源等。
从目前技术应用范围和成熟度看，推荐使用第一种方式(本地事务发布事件)，来实现事件投递原子化，即可靠事件投递。
SpringCloud和Dubbo有哪些区别？
总体来说，两者各有优势。虽说后者服务调用的功能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的依赖，这在强调快速演化的微服务环境下，显得更加合适。
品牌机与组装机的区别：很明显SpringCloud比dubbo的功能更强大，覆盖面更广，而且能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美融合，这些对于微服务至关重要。使用Dubbo构建的微服务架构就像组装电脑、各环节我们选择自由度高，但是最总可能会因为内存质量而影响整体，但对于高手这也就不是问题。而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性。
在面临微服务基础框架选型时Dubbo与SpringCloud只能二选一。
优点：易于开发和维护:一项服务只关注一项特定的业务功能，业务清晰，代码量少。
微型服务的优点:
1.易于开发和维护:一项服务只关注一项特定的业务功能，业务清晰，代码量少。开发维护单项微服务相当简单。整个应用程序由一些微型服务构建，因此整个应用程序处于可控状态。
2.单一服务启动快:单一服务代码少，启动快。
3.局部修改易于部署:单个应用程序只要有修改，就必须重新部署整个应用程序，微服务解决了这个问题。一般来说，修改某个微型服务，只需重新配置该服务。
4.技术堆栈不受限制:微服务结构可结合业务和团队特点，合理选择技术堆栈。例如，一些服务可以使用关系数据库Mysql，一些服务可以使用非关系数据库redis。甚至可以根据需服务可以使用JAVA开发，一些微服务可以使用Node.js开发。
5.按需收缩:可根据需要实现细粒度的扩展。例如，系统中的某个微服务遇到瓶颈，可以结合微服务的特点，增加内存，升级CPU，增加节点。
微型服务的缺点:
1.运输要求高:更多的服务意味着更多的运输投入。在单体结构中，只需保证一个应用程序的运行，在微服务中，需要保证几十到几百个服务器的正常运行和合作，这给运行维护带来了巨大的挑战
2.分户式固有的复杂性:使用微服务结构的是分布式系统。对于分布式系统，系统容错，网络延迟带来巨大挑战。
3.界面调整成本高:微服务之间通过界面通信。
什么是微服务？
微服务(Microservices Architecture)是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务的概念源于2014年3月Martin Fowler所写的文章“Microservices” martinfowler.com/articles/mi…
单体架构(Monolithic Architecture )
企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。
这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包
上图：单体架构
大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。
多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。
单体架构的应用一般有以下特点：
微服务架构（Microservices Architecture）
微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！
上图：微服务架构
微服务设计
那我们在微服务中应该怎样设计呢。以下是微服务的设计指南：
微服务消息
在单体架构中，不同功能之间通信通过方法调用，或者跨语言通信。SOA降低了这种语言直接的耦合度，采用基于SOAP协议的web服务。这种web服务的功能和消息体定义都十分复杂，微服务需要更轻量的机制。
同步消息 REST
同步消息就是客户端需要保持等待，直到服务器返回应答。REST是微服务中默认的同步消息方式，它提供了基于HTTP协议和资源API风格的简单消息格式，多数微服务都采用这种方式（每个功能代表了一个资源和对应的操作）
异步消息 – AMQP, STOMP, MQTT
异步消息就是客户端不需要一直等待服务应答，有应到后会得到通知。某些微服务需要用到异步消息，一般采用AMQP, STOMP, MQTT 这三种通讯协议
消息格式 – JSON, XML, Thrift, ProtoBuf, Avro
消息格式是微服务中另外一个很重要的因素。SOA的web服务一般采用文本消息，基于复杂的消息格式（SOAP）和消息定义（xsd）。微服务采用简单的文本协议JSON和XML，基于HTTP的资源API风格。如果需要二进制，通过用到Thrift, ProtoBuf, Avro。
服务约定 – 定义接口 – Swagger, RAML, Thrift IDL
如果把功能实现为服务，并发布，需要定义一套约定。单体架构中，SOA采用WSDL，WSDL过于复杂并且和SOAP紧耦合，不适合微服务。
REST设计的微服务，通常采用Swagger和RAML定义约定。
对于不是基于REST设计的微服务，比如Thrift，通常采用IDL（Interface Definition Languages），比如Thrift IDL。
微服务集成 (服务间通信)
大部分微服务基于RPC、HTTP、JSON这样的标准协议，集成不同标准和格式变的不再重要。另外一个选择是采用轻量级的消息总线或者网关，有路由功能，没有复杂的业务逻辑。下面就介绍几种常见的架构方式。
点对点方式
点对点方式中，服务之间直接用。每个微服务都开放REST API，并且调用其它微服务的接口。
上图：通过点对点方式通信
很明显，在比较简单的微服务应用场景下，这种方式还可行，随着应用复杂度的提升，会变得越来越不可维护。这点有些类似SOA的ESB，尽量不采用点对点的集成方式。
API-网关方式
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能个。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
上图：通过API-网关暴露微服务
所有的业务接口通过API网关暴露，是所有客户端接口的唯一入口。微服务之间的通信也通过API网关。\
采用网关方式有如下优势：
目前，API网关方式应该是微服务架构中应用最广泛的设计模式。
消息代理方式
微服务也可以集成在异步的场景下，通过队列和订阅主题，实现消息的发布和订阅。一个微服务可以是消息的发布者，把消息通过异步的方式发送到队列或者订阅主题下。作为消费者的微服务可以从队列或者主题共获取消息。通过消息中间件把服务之间的直接调用解耦。
上图：异步通信方式
通常异步的生产者/消费者模式，通过AMQP, STOMP, MQTT 等异步消息通讯协议规范。
数据的去中心化
单体架构中，不同功能的服务模块都把数据存储在某个中心数据库中。
每个微服务有自己私有的数据库，其它微服务不能直接访问。单体架构，用一个数据库存储所有数据
微服务方式，多个服务之间的设计相互独立，数据也应该相互独立（比如，某个微服务的数据库结构定义方式改变，可能会中断其它服务）。因此，每个微服务都应该有自己的数据库。
每个微服务有自己私有的数据库，其它微服务不能直接访问。每个微服务有自己私有的数据库，其它微服务不能直接访问。
数据去中心话的核心要点：
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。
微服务架构的优点：
微服务架构的缺点：
微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。
关于微服务架构的取舍
微服务架构是一项在云中部署应用和服务的新技术。
大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。
微服务架构相关介绍：
微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。
在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。
如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。
服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
