微服务应用
通常在单体系统中，开发者会在类、模块、类库的层面来设计功能属性，而在微服务应用中，开发者的目标则变成了可独立部署的功能单元，而每个功能单元以一些复杂的方式进行交互，功能单元之间的相互协作则是通过一系列消息协议来完成，而这些协议可能是点对点的也可能是异步的，每个功能单元共同合作起来形成了一个更加复杂的系统
微服务发展至今已并非新鲜事物，而其定义也非常容易理解，但它确实能够显著的降低复杂系统开发过程中的相互牵扯和冲突，且同时具备了软件工程实践倡导的【高内聚】【低耦合】，很显然具备这样特点的系统更容易维护、易扩展，通过这些手段完成为客户持续交付价值的最终目的，这里的重点在于持续交付，而如果更高维度考虑，将其与商业行为结合，这个最终目的应该是为客户快速的持续的交付价值，于是这里的重点便多了一个维度即快速的持续的
微服务特点
概念是非常容易懂的，稍微有几年开发经验的开发者一看便知道其中的意义，但到了实操层面具体该怎么做技术设计又无从下手，如果说微服务的概念告诉了我们它解决了什么问题，那么微服务的几个特点【我更愿称之为原则】告诉了我们应该如何做技术设计
内聚度时用来衡量某个模块中的各个元素属于一个整体的紧密程度的指标，耦合度则是衡量一个元素对另一个元素的内部运转逻辑了解程度的指标，而在讨论内聚和耦合的时候，单一职责原则便是一个很少的提升内聚的手段即：将那些因相同原因而修改的内容聚合到一起，将那些因不同原因而修改的内容进行拆分
单个微服务应该是高内聚的，它应该只负责应用的一个功能，同样每个服务对其他服务的内部运转逻辑知道的越少就越容易修改，而不需要让其他服务跟着一起修改
考虑一下出售股票的场景，大致需要如下4步处理
用户创建一个订单，用来出售其账户里某只股票的股份
账户中的这部分持仓就会被预留下来，确保相同的股份不可以被多次出售
提交订单到市场上需要缴纳印花税
系统需要将这个订单发送给对应的股票交易市场
如图所示微服务设计，它是整个交易系统的一部分
从图中可以看到，微服务的三大关键特点：
每个微服务只负责一个功能，这个功能可能是业务相关的功能，也可能是共用的技术功能，比如与第三方的集成
每个微服务都拥有自己的数据存储，这是降低耦合非常关键的设计，各服务之间的数据访问，仅可以通过服务提供的接口来访问它们自己所不拥有的数据
微服务自己负责编排和协作(控制消息和操作的执行顺序来完成某些有用的功能)，既不是由连接微服务的消息机制来完成的，也不是通过另外的软件功能来完成的
除了以上的三大特点外，还有两个基本特性：
每个微服务都可以独立部署，如果做不到，那么到了部署阶段微服务应用还是一个庞大的单体应用，而团队不能仅仅考虑到coding的部分，还需要考虑部署、监控、诊断等一些列环节，如此微服务才能发挥其作用
每个微服务都是可代替的，每个微服务只具备一项功能，所以这很自然地限制了服务的大小，同时每个服务的职责或角色更加易于理解
微服务与传统的面向服务架构soa有一个关键区别，微服务负责协调系统中的各个操作，而soa类型的服务通常通过使用企业服务总线esb或者更复杂的编排标准将应用本身与消息和流程编排拆开，在soa模型下，服务通常缺乏内聚度，因为业务逻辑会不断地添加到服务总线上，而非服务本身
可以针对每个问题选择最合适的技术工具，无需多个服务死板的采用固有的技术和工具
自治和独立部署意味着可以分别管理这些微服务所对应的资源需求，同时减少故障，不会因某个服务故障导致其他服务连锁故障
自治性也使得开发者可以独立的对这些服务进行开发、部署和扩容
自治性、可恢复性、透明性、自动化和一致性
非常明确的是微服务是自治的，每个服务的操作和修改都是独立于其他服务的，那么为了保证自治性，开发者需要将服务设计得松耦合、可独立部署
每个微服务通过明确定义的接口或者发布的事件消息来与其他服务进行交互，这些交互需独立于协作方的内部实现
不同的服务通常由多个不同的团队并行开发，因此独立部署则成为快速交付价值的非常关键环节，也因此各服务之间相对完全独立
自治性也是团队文化，各个服务的责任和所有权委派给有责任交付商业价值的团队，这是非常关键的管理决策，组织的设计会对系统设计产生影响，清晰的服务所有权有助于团队基于他们本身所处的环境和目标迭代开发和做技术决策
微服务与生俱来的具备故障隔离的机制，如果开发者独立的部署这些微服务，那么当应用或者基础设施出现故障，故障只会影响到整个系统一部分功能，同样部署功能的粒度越小、开发者越能更平缓的对系统进行变更
当故障发生时，开发者需要记得微服务应用是依赖于多个服务之间的交互及其表现的，而这些服务是由不同的团队开发的，因此无论在什么时候系统都应该是透明的、可观测的，如此更有利于发现问题诊断问题解决问题
通过开发大量的服务来缓解应用不断变化所带来的痛苦，看似有悖常理，事实上相对一单体系统，微服务确实是一种更加复杂的架构，通过采用自动化和在基础设施内保持服务之间的一致性，开发者可以极大地降低因为这些额外的复杂性引入的管理成本，通过自动化也可以保证部署和系统运维过程中的正确性
微服务架构的流行与两种趋势是同时发生的，一种趋势是devops技术的得到了主流接纳，其中典型的就是**基础设施即代码(infrastructure-as-code)**技术；另一种趋势是完全通过api进行编程的基础设施环境(如aws和azure)的兴起，三者同时发生并非巧合
以恰当的方式调整开发工作至关重要，开发者的目标应该是围绕业务实体来组织服务和团队，只有如此服务和团队的内聚性才能更高