<p><img src="https://simg.open-open.com/show/efbd41f0d70a14afd2cfa941087b25c1.jpg"></p>    <p>现在天天把“微服务”挂在嘴边的人很多，为什么要搞微服务架构?有多少人真正深入思考过“为什么”，我认为可能不多。</p>    <p><img src="https://simg.open-open.com/show/b4ee9674fe1d76e8187de167963ff520.jpg"></p>    <p>于是我在梳理材料的时候，就决定从源头入手——即“为什么”。</p>    <p><img src="https://simg.open-open.com/show/f5a1e8fafe89aaddde500252da6e5e62.jpg"></p>    <p>架构是演进的，不是一蹴而就</p>    <p><img src="https://simg.open-open.com/show/28316852f8879d5c1661695b1dca4cad.jpg"></p>    <p>“架构演进趋势图”中的趋势分析，在业界比较公认。这个图本身的内容、关于各个架构的描述、优缺点等等，网上简单搜索一下有大把大把的。</p>    <p>软件发展的不同时期、阶段，对技术的理解、选择和应用都有着不一样的诉求。架构的选型，永远只有“合适与不合适”，永远没有“哪个更好”的说法。我们今天来谈论微服务，并不是因为它更牛，而是经过谨慎分析，认为微服务的思想更符合我们的目标。</p>    <p>什么是微服务架构?</p>    <p><img src="https://simg.open-open.com/show/b52d63c13d87033052d4fac0dbf9e1db.jpg"></p>    <p>既然聊的是“为什么”，那么首先要明白“什么是”。</p>    <p>“一解释就懂，一问就不知，一讨论就打架”，这是之前我在网上看到的一句话，笑了好久，太贴切了，就搬了过来。</p>    <p><img src="https://simg.open-open.com/show/b71ecd881419daa69b5dd661118998d9.jpg"></p>    <p>提到微服务，就没法不提到这位“大神”——马丁·福勒，他没有直接给微服务下一个精准的定义，而是给出了微服务特点的描述。</p>    <p>大概从以下四个方面来说：</p>    <ul>     <li>根据业务模块划分服务种类。</li>     <li>每个服务可以独立部署并且互相隔离。</li>     <li>通过轻量的 API 调用服务。</li>     <li>服务需要保证良好的高可用性。</li>    </ul>    <p><img src="https://simg.open-open.com/show/effc0189a93b1340a63a9625117c5b04.jpg"></p>    <p>怎么理解呢?以下是我的解读：</p>    <p>按业务拆分服务， 这是“水平拆分”;在技术层面的“前后分离”，属于“垂直拆分”;横纵一起切，就把单一的应用拆分成网状的小块应用，这是微服务中“微”思想的体现。</p>    <p>独立部署与互相隔离， 这点充分体现了“我为人人、人人为我”的设计理念，这是微服务中「服务」思想的体现。</p>    <p>关于轻量 API， 微服务本身是推荐使用轻量的通讯协议和简单的数据结构，实际上，实施环节通常采用的都是 http+json 的方式。</p>    <p>这样做的好处是，服务之间不再需要关心对方的模型，仅通过事先约定好的接口来进行数据流转即可。这是微服务中“解耦”思想的体现。</p>    <p>最后一点，比较通用了，就是现如今各种设计都必须考虑的事情。于是，我给微服务下了一个定义，如下图：</p>    <p><img src="https://simg.open-open.com/show/e9f4813d905c28f1e66c55955d3a8d50.jpg"></p>    <p>在实际工作中，我们遇到过各式各样的问题，有些是技术问题，有些是业务问题，还有些是管理问题，这里拿其中一个案例来说一下。</p>    <p><img src="https://simg.open-open.com/show/ebab40103333de5f8ffc157d289e25ad.jpg"></p>    <p>这种事情说大不大，说小不小，其中最麻烦的事情是“推诿”的发生。每个独立组织都有自己的考核指标和关注点，而实际情况又不可能把具体的一个任务的界限划分得特别清晰。</p>    <p>例如接口定义，哪怕说的是“双方坐下来一起商讨决定”，最终还是会有一方对此事负责，推诿在所难免。</p>    <p>微服务的指导思想其中一块就是关于组织机构调整的，这还有个专门的定律叫“康威定律”。</p>    <p>我们的解决办法也很有效果，在组织机构没有完全按照微服务的理念重新规划之前，这类需要跨组织协同完成的任务，直接成立临时项目组：相关的部门出人的出人、出资源的出资源，指定/选拔一个能 hold 住的项目经理对整件事情负责。</p>    <p>然后大家惊奇的发现：“部门墙”问题不见了，因为所有事情都是组内事情了，整体的完成情况跟全部项目组成员的业绩都挂钩了，事情推进就非常顺利。</p>    <p>在顺利交付之后，项目组解散，各回各家。极大的提升了沟通效率、交付速度，同时使得资源利用率也得到了很大的提升。</p>    <p>其实很多时候，大家解决问题的想法和思路，并不是要有了微服务才这样做，而是“不谋而合”，微服务就存在于我们日常工作的点点滴滴之中。</p>    <p><img src="https://simg.open-open.com/show/8d830cd5e422857f6dc1ad155b7f93e1.jpg"></p>    <p>要搞微服务了，有啥建议么?通过我们不断的摸索和总结，要做好微服务，就要做好一定的准备工作。</p>    <p>从五个具体的方面来谈：</p>    <p>业务拆分，体现在设计环节： 在设计的时候，要有足够的判断力来合理的规划服务之间的界限。</p>    <p>服务治理，底层技术的支持： 首先要选一款适合自己实际情况的分布式服务基础框架，对于服务的发现、治理、熔断、降级，都要做好相应的技术准备。</p>    <p>自动测试，一定要自动化。 微服务一个明显的表象就是随着服务的增多，如果继续沿用传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到更多的环节实现自动化。</p>    <p>自动运维 ： 微服务拆分之后，每个服务都可以独立部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。</p>    <p>监控： 包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话：没准备好监控，就不要搞微服务。</p>    <p><img src="https://simg.open-open.com/show/7dd3359867633122f84fa545db0a8527.jpg"></p>    <p>最后，微服务不是银弹，软件领域没有银弹，微服务以其特有的优势在解决一些问题的同时，也引入了其他问题，以下这几点，必须要深刻的思考，三思而后行。</p>    <p><img src="https://simg.open-open.com/show/2aa8d0598127e02298c326e076520f00.jpg"></p>    <p> </p>    <p>来自：http://developer.51cto.com/art/201707/545735.htm</p>    <p> </p>