微服务设计思想和目标
微服务是业界越来越流行的架构模式之一，它的中心思想就是将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，形成一个松耦合、功能隔离的服务架构。
微服务架构是在单体架构的基础上演变而来，它的出现为了解决单体架构的一些问题，如果想深入了解微服务架构的设计思想和目标，就必须了解架构模式演变的历史。
# 单体架构
最开始Web服务器、数据库全部部署在同一台服务器上，这也是最简单的应用架构，通常公司早期项目都采用这种方式。在很长一段时间里单体结构可以满足系统快速开发与并发量的需求。当用户量越来越大，通常会数据库性能会成为系统瓶颈，此时可以将Web业务与数据库部署在不同服务器上，增强数据库服务器的配置并做读写分离等提高系统的吞吐量与可用性。
与此同时也可以将业务系统等价部署在多台服务器上来提高系统吞吐量，但整体上这仍然是一个单体应用。随着用户、数据量进一步增大，单体应用的缺点会进一步显露出来，比如：
复杂性高
整个项目包含的模块非常多，模块的边界模糊，依赖关系不清晰，代码质量参差不齐,整个项目非常复杂。每次修改代码都心惊胆战，甚至添加一个简单的功能，或者修改一个BUG都会造成隐含的缺陷。
技术债务逐渐上升
随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。
部署速度逐渐变慢
随着代码的增加，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响范围大、风险高，这使得单体应用项目上线部署的频率较低，从而又导致两次发布之间会有大量功能变更和缺陷修复，出错概率较高。
扩展能力受限，无法按需伸缩
单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。
阻碍技术创新
单体应用往往使用统一的技术平台或方案解决所有问题，团队的每个成员都必须使用相同的开发语言和架构，想要引入新的框架或技术平台非常困难。
# 微服务架构
微服务提倡将单一服务拆分成一组小服务、服务之间相互协调、配合，提高开发效率，最终为用户提供价值服务。那么，微服务里面最重要的一个问题就是服务应该怎么拆。
# 垂直拆分
微服务作为 SOA（Service Oriented Architecture）思想的一种具体实践，首先想到的就是按照不同的业务系统做垂直拆分，如下图所示：
按业务系统对单体应用做垂直拆分，不同的业务线完全可以独立配备产品经历与工程师同步开发维护，将不同业务线解耦出来有不同团队维护。
但上图是一种理想情况，各系统拆分力度比较大，系统之间不需要更详细的通信。如果是被拆除出了的子系统之间有大量的数据交互与调用，网关模式便不是一种很好的实践，通常会将各业务子系统接入一个数据总线用 ESB（Enterprise Service Bus）模式来进行数据交互，各子系统与数据总线进行数据交换便需要对子系统做统一管理，这遍有了 服务治理 的概念，用一套统一的保准来处理各子系统的注册、权限、监控等。
# 水平拆分
垂直拆分将各业务子系统解耦出来，但是每次请求在不同阶段遇到的瓶颈与负载是不一样的，因此我们对可以使用水平拆分的思路对服务进行拆分：
首先用户请求通过http协议到达网关，网关将json数据格式转为protobuf，通过tcp长链接与服务层、数据层通信获取目标数据然后返回给用户。这样拆分加长了用户请求链路时延，但是如果服务全部部署在同一内网，而且使用protobuf格式通信那么这个时延在几十毫秒内是完全可以接受的。业务层与数据层完全解耦便可以轻松将不同类型的服务进入冗余部署，同时在不动业务层的同时修改它的数据存储方式。
如果我们对系统即做垂直拆分也做水分拆分，那么就有了微服务的样子,
每级服务只能调用比他低级别的服务，例如搜索服务层只能调用账户数据层服务而不能调账户服务层接口，这样可以用来避免服务A调用服务B，而服务B同时又调用了服务A的循环调用问题。
但是这样的拆分粒度仍然不够的，比如搜索系统和推荐系统都要调用账户系统的一些基础查询、修改逻辑，那么需要在搜索与推荐的服务层两次实现同样的代码吗，这样显然是不合理了，任何不能复用的设计显然都是有问题的，这里可以将每个子系统可共用代码部分也单独抽取出来作为一个服务。
这样拆分后的系统可以灵活部署，独立开发，并且各模块服务使用的技术栈相对独立不受限制。但是同时拆分也将系统的网络拓扑便的复杂，运维负担加重，服务间的依赖使得服务接口的调整成本非常高。服务增多的同时对服务治理的要求也更高，需要专门做服务的发现、注册、鉴权、监控等系统功能
# 微服务治理
单体应用在改成微服务架构应用之后，越来越多的系统被拆解成了很多个细胞一样的微服务。设想一下，如果你的系统有100个微服务构成，要对这100个微服务进行管理，这绝对是一个不小的挑战，因此衍生出了不少概念：服务注册发现，请求链路追踪，服务熔断，服务限流，服务管控配置，服务预警...
# 总结
随着业务需求的快速发展变化，敏捷性、灵活性和可扩展性需求不断增长，迫切需要一种更加快速高效的软件交付方式。微服务就是一种可以满足这种需求的软件架构风格。单体应用被分解成多个更小的服务，每个服务有自己的归档文件，单独部署，然后共同组成一个应用程序。这里的“微”不是针对代码行数而言，而是说服务的范围限定到单个功能。通过解耦我们所做的事情，分而治之以减少不必要的损耗，使得整个复杂的系统和组织能够快速的应对变化。