每天都有很多人在谈论“微服务”。为什么要搞微服务架构？有多少人真正深入思考过“为什么”，我想可能并不多。所以我在整理资料的时候，决定从源头——也就是“为什么”入手。架构的发展不是一蹴而就的。《架构演进趋势图》中的趋势分析在业界是比较认可的。图片本身的内容，各个架构的描述，优缺点等等，网上有很多简单的搜索。软件开发的不同时期和阶段对技术的理解、选择和应用有不同的要求。在架构的选择上，永远只有“合适不合适”之分，从来没有“哪个更好”之分。我们今天谈论微服务并不是因为它更好，而是我们仔细分析后认为微服务的思想更符合我们的目标。什么是微服务架构？既然说“为什么”，就要先了解“是什么”。“一解释就明白，一问就不知道，一讨论就打架。”这是之前在网上看到的一句话，笑了很久。太合适了，所以我把它移到了这里。说到微服务，就不可能不提这位“大神”——MartinFowler。他并没有直接给出微服务的精确定义，而是对微服务的特点进行了描述。大概从以下四个方面入手：按业务模块划分服务类型。每个服务都可以独立部署，相互隔离。通过轻量级API调用服务。服务需要保证良好的高可用性。你怎么理解的？以下是我的解读：按业务拆分服务是“横向拆分”；技术层面的“前后分离”是“纵向拆分”；拆分成小的网状应用是微服务中“微”思想的体现。独立部署，相互隔离，充分体现了“我为大家，大家为我”的设计理念，是“服务”思想在微服务中的体现。关于轻量级的API，微服务本身推荐使用轻量级的通信协议和简单的数据结构。实际上，实现过程通常使用http+json。这样做的好处是服务不再需要关心彼此的模型，只使用预先约定的接口进行数据流转。这就是“解耦”思想在微服务中的体现。最后一点就是比较通用，是现在各种设计必须要考虑的东西。于是，我给出了微服务的定义，如下图所示：在实际工作中，我们遇到了各种各样的问题，有的是技术问题，有的是业务问题，有的是管理问题。下面就其中一个案例讲一下。这种事情不管是大事还是小事，最头疼的就是“推诿”的发生。每个独立的机构都有自己的考核指标和关注点，在实际情况下不可能明确划定具体任务的边界。比如接口定义，即使说“双方坐下来共同商量决定”，最终还是要有一方负责，搪塞在所难免。微服务的指导思想之一就是组织调整，有一个特殊的规律叫“康威定律”。我们的解决方案也非常有效。在组织完全按照微服务的理念重新规划之前，这种需要跨组织协作的工作，直接成立临时项目组：相关部门派人、派资源。要分配资源，指定/选择一个项目经理来负责整个项目。然后大家惊讶地发现“部门墙”的问题消失了，因为一切都是在组内完成的，整体的完成与所有项目组成员的绩效挂钩，所以事情进行的非常顺利。交付成功后，项目组解散，各回各家。沟通效率和传递速度得到了极大的提升，资源利用率也得到了极大的提升。其实很多时候，大家解决问题的想法和思路，并不是只有有了微服务才这样做，而是“巧合”。微服务存在于我们日常工作的点点滴滴中。您对从事微服务有什么建议吗？通过我们不断的探索和总结，要做好微服务，必须要做好一定的准备工作。下面具体说一下五个方面：业务拆分，体现在设计过程中：在设计的时候，我们要有足够的判断力，合理规划服务之间的边界。服务治理、底层技术支撑：首先，选择适合自己实际情况的分布式服务基础架构，并做好相应的服务发现、治理、熔断、降级等技术准备。自动测试必须是自动化的。微服务的一个明显表现是，随着服务的增加，如果继续使用传统的测试模式，就会遇到瓶颈。为了保证高效的迭代，尽量自动化尽可能多的环节。自动化运维：微服务拆分后，每个服务都可以独立部署，并且可以随时随地升级。尤其是在互联网发达的今天，业务必须保持对市场变化的高效响应，而自动化运维是提高交付速度的重要环节。监控：包括硬件环境、服务状态、系统健康度、接口调用、异常实时告警、潜在问题预警等。监控在微服务实施过程中重要到什么程度？一句话：没做好监控就别搞微服务。***，微服务不是灵丹妙药。软件领域没有灵丹妙药。微服务以其独特的优势解决了一些问题，但也引入了其他问题。以下几点一定要深思熟虑，三思而后行。
