《微服务》八特性--标注性考究
特性1：服务组件化
组件，是一个可以独立更换和升级的单元。就像PC中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。
在“微服务”架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，它通过http等通信协议进行协作，而不是传统组件以嵌入的方式协同工作。服务都独立开发、部署，可以有效的避免一个服务的修改引起整个系统的重新部署。
打一个不恰当的比喻，如果我们的PC组件以服务的方式构建，我们只维护主板和一些必要外设之后，计算能力通过一组外部服务实现，我们只需要告诉PC我们从哪个地址来获得计算能力，通过服务定义的计算接口来实现我们使用过程中的计算需求，从而实现CPU组件的服务化。这样我们原本复杂的PC服务得到了更轻量化的实现，我们甚至只需要更换服务地址就能升级我们PC的计算能力。
考究：
这个思想在我们实际的软件实施中很早就用过，但依然不会标准和统一，问题的根本是什么？企业应用的当时实际场景决定,因此这个不能全部套用，但起码要做到基础架构上可装可卸，可伸可缩
特性2：按业务组织团队
当我们开始决定如何划分“微服务”时，通常也意味着我们要开始对团队进行重新规划与组织。按以往的方式，我们往往会以技术的层面去划分多个不同的团队，比如：DBA团队、运维团队、后端团队、前端团队、设计师团队等等。若我们继续按这种方式组织团队来实施“微服务”架构开发时，当有一个有问题需要更改，可能是一个非常简单的变动，比如：对人物描述增加一个字段，这就需要从数据存储开始考虑一直到设计和前端，虽然大家的修改都非常小，但这会引起跨团队的时间和预算审批。
在实施“微服务”架构时，需要采用不同的团队分割方法。由于每一个微服务都是针对特定业务的宽栈或是全栈实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种跨专业领域的职能。因此，面对大型项目时候，对于微服务团队拆分更加建议按业务线的方式进行拆分，一方面可以有效减少服务内部修改所产生的内耗；另一方面，团队边界可以变得更为清晰。
考究：
什么样的业务线边界适合呢？保证质量下，消耗比是否真能降下去？
特性3：做“产品”的态度
实施“微服务”架构的团队中，每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。而不是以项目的模式，以完成开发与交付并将成果交接给维护者为最终目标。
开发团队通过了解服务在具体生产环境中的情况，可以增加他们对具体业务的理解，比如：很多时候一些业务中发生的特殊或异常情况，很可能产品经理都并不知晓，但细心的开发者很容易通过生产环境发现这些特殊的潜在问题或需求。
所以，我们需要用做“产品”的态度来对待每一个“微服务”，持续关注服务的运作情况，并不断地分析帮助用户来提升业务功能。
考究：
学院派了，没实际用处
特性4：智能端点与哑管道
在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在“微服务”架构中，服务由于不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改成RPC方式的调用，会导致微服务之间产生繁琐的通信，使得系统表现更为糟糕，所以，我们需要更粗粒度的通信协议。
在“微服务”架构中，通常会使用这两个服务调用方式：
第一种，使用HTTP协议的RESTful API或轻量级的消息发送协议，来实现信息传递与服务调用的触发。
第二种，通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的结构。
在极度强调性能的情况下，有些团队会使用二进制的消息发送协议，例如：protobuf。即使是这样，这些系统仍然会呈现出“智能端点和哑管道”的特点，为了在易读性与高效性之间取得平衡。当然大多数Web应用或企业系统并不需要作出在这两者间做出选择，能够获得易读性就已经是一个极大的胜利了。 ——Martin Fowler
考究：
Martin Fowler的说法靠谱
特性5：去中心化治理
当我们采用集中化的架构治理方案时，通常在技术平台上都会做同一的标准，但是每一种技术平台都有其短板，这会导致在碰到短板时，不得不花费大力气去解决，并且可能还是因为其底层原因解决的不是很好。
在实施“微服务”架构时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样我们整个“微服务”架构的系统中的组件就能针对其不同的业务特点选择不同的技术平台，终于不会出现杀鸡用牛刀或是杀牛用指甲钳的尴尬处境了。
不是每一个问题都是钉子，不是每一个解决方案都是锤子
考究：
学院派，不实用
特性6：基础设施自动化
近年来云计算服务与容器化技术的不断成熟，运维基础设施的工作变得越来越不那么难了。但是，当我们实施“微服务”架构时，数据库、应用程序的个头虽然都变小了，但是因为拆分的原因，数量成倍的增长。这使得运维人员需要关注的内容也成倍的增长，并且操作性任务也会成倍的增长，这些问题若没有得到妥善的解决，必将成为运维人员的噩梦。
所以，在“微服务”架构中，请务必从一开始就构建起“持续交付”平台来支撑整个实施过程，该平台需要两大内容，不可或缺：
自动化测试：每次部署前的强心剂，尽可能的获得对正在运行软件的信心。
自动化部署：解放繁琐枯燥的重复操作以及对多环境的配置管理。
考究：
这个可用有，传统意义也有，只是因为云计算而不同
特性7：容错设计
在单体应用中，一般不存在单个组件故障而其他还在运行的情况，通常是一挂全挂。而在“微服务”架构中，由于服务都运行在独立的进程中，所以是存在部分服务出现故障，而其他服务都正常运行的情况，比如：当正常运作的服务B调用到故障服务A时，因故障服务A没有返回，线程挂起开始等待，直到超时才能释放，而此时若触发服务B调用服务A的请求来自服务C，而服务C频繁调用服务B时，由于其依赖服务A，大量线程被挂起等待，最后导致服务A也不能正常服务，这时就会出现故障的蔓延。
所以，在“微服务”架构中，快速的检测出故障源并尽可能的自动恢复服务是必须要被设计和考虑的。通常，我们都希望在每个服务中实现监控和日志记录的组件，比如：服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。
考究：
这个可用有，但传统意义的软件也有，只是场景有区别
特性8：演进式设计
通过上面的几点特征，我们已经能够体会到，要实施一个完美的“微服务”架构，需要考虑的设计与成本并不小，对于没有足够经验的团队来说，甚至要比单体应用发付出更多的代价。
所以，很多情况下，架构师们都会以演进的方式进行系统的构建，在初期系统以单体系统的方式来设计和实施，一方面系统体量初期并不会很大，构建和维护成本都不高。另一方面，初期的核心业务在后期通常也不会发生巨大的改变。随着系统的发展或者业务的需要，架构师们会将一些经常变动或是有一定时间效应的内容进行“微服务”处理，并逐渐地将原来在单体系统中多变的模块逐步拆分出来，而稳定不太变化的就形成了一个核心“微服务”存在于整个架构之中。
考究：
这个实际
