推酷《编程狂人》第一二三期 - 简书
推酷《编程狂人》第一二三期
推酷诚意满满的技术周刊《编程狂人》， 下面是内容列表，干货多多，也可以移步到官网。
推酷专注于IT领域的信息挖掘和推荐，给你全栈式高效阅读体验。主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
傻丫头和高科技产物小心翼翼的初恋
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：。个人QQ群：、
个人大数据技术博客：
人生得意须尽欢，莫使金樽空对月。重庆域名服务热线 ：023-22
阿里云应用开发
&&>>&&&&&&&&&&&&
为什么我们需要微服务架构
&　　为什么我们需要微服务架构　　最近这几年，伴随着云计算技术的进步以及服务的增长，微服务逐渐成为在博客、媒体讨论组和会议演讲中出现的热门话题，这也让它被更多的人重点关注。尽管微服务架构存在着非常多争论，但这并不影响它正在为敏捷部署以及复杂企业应用实施提供着巨大的帮助的事实。为什么我们需要微服务架构?与传统SOA相比，微服务架构有哪些优势?在使用微服务架构时，我们又将面临哪些挑战?本文将一一为你揭晓!　　一、关于微服务的理解　　2012年微服务这一概念大致开始出现，是因软件作者Martin Fowler而流行，围绕业务、自动化部署、终端智能以及语言和数据的分散控制有一些常见的新特性。随着云计算技术的进步和服务的增长，微服务架构越来越多的受到了人们的关注。微服务也是一项在云中部署应用和服务的新技术。虽然也存在着许多不同的争论，微服务架构模式却正在为敏捷部署以及复杂企业应用实施提供着巨大的帮助。　　一般来说，我们的开发也是模块化设计逻辑，程序完成后会打包并部署为一个个具体的应用。每个具体的格式依赖于相应的应用语言和框架。举个例子，Java应用通常会被打包为WAR格式，部署在Tomcat或者Jetty上，而另外一些Java应用会被打包成自包含的JAR格式，同样，Rails和Node.js会被打包成层级目录。这种应用开发风格很常见，也很易于调试，只需要简单运行此应用，用些工具链接UI就可以完成端到端测试。打包好的应用拷贝到服务器端，通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早期这类应用运行的都很好，但一个简单的应用会随着时间推移逐渐变大。几年后，这个小而简单的应用会变成了一个巨大的怪物。一旦你的应用变成一个庞大而又复杂的怪物，那开发团队肯定会很痛苦。敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能将变的非常困难，并且很耗时。　　当一个应用越大，启动时间就会越长。那么大部分时间就要在等待中渡过，生产效率会受到极大影响。　　另外，一个应用在不同模块发生资源冲突时，扩展将会十分的困难。应用的另外一个问题是可靠性。当所有模块都运行在一个进程中，任何一个模块中的一个bug，比如说，内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个bug将会影响到整个应用的可靠性。　　如果采用微服务处理结构模式则可以很好的解决上述问题。微服务架构的思想不是开发一个复杂巨大的应用，而是将应用分解为若干小的、互相连接的微服务。　　二、微服务的六大优势　　微服务架构相对于传统的SOA，优势也很明显：　　优势1、功能特定：一个微服务一般完成某个特定的功能，比如消息管理、客户管理等等。每一个微服务都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。　　优势2、复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。　　优势3、独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。　　优势4、技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，当需要对技术栈进行升级时所面临的风险较低，甚至完全重构一个微服务也是可行的。　　优势5、容错：当某一组建发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。　　优势6、扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。　　三、微服务的三大挑战　　挑战1：波及多个服务：最后一个问题在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个项目案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单个应用中，你只需要改变相关模块，整合变化，部署就好了。相比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。　　挑战2：固有的复杂性：微服务架构有很多优点，当然也有其不足。比如微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。　　挑战3：分区的数据库架构：另外一个关于微服务的挑战来自于分区的数据库架构。在商业交易系统中同时给多个业务分主体更新消息很普遍。这种交易对于单个应用来说很容易，因为只有一个数据库。而在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。　　使用微服务构建适合云的新型应用是很有意义的，因为它让你既利用了横向扩展架构，也利用了纵向扩展架构，还额外得到API的组合，且在整个业务中可重复利用。可能在每一分钟都在交付新服务，这样你就会拥有一个敏捷的且即时响应的应用程序平台，当然这一平台一直在不断改进中，微服务架构也在前进着。　　四、微服务的主要周边技术　　1)、微服务与PAAS　　2)、DOCKER容器　　3)、微服务与数据库　　4)、微服务与数据一致性　　5)、微服务与分布式　　6)、微服务架构与SOA　　7)、云VM　　8)、微服务与Mesos或者Kubernetes　　9)、微服务与自动化部署　　10)、微服务层面如何提供缓存、权限控制、API统计和监控
&&相关问题
&&热门问题
服务与支持微服务应该怎样服务后端业务系统？
企业软件 We Are Professional
微服务应该怎样服务后端业务系统？
“微服务化一词近来热度十足，是人云亦云还是确有两把刷子，本文从三个部分为您详解微服务化改造。1业务系统：看似简单实则复杂业务系统是任何一个用户产品的必须组成，充当着一个门面的角色，用户的输入就是这个系统需要维护的，数据存取是整个系统的核心。例如，广告业务系统的输入是广告主的投放约束、定向条件，微博业务系统的输入是短文字、图片等。在应用发展初期或者规模不大的情况下，有非常简单的实现方案，LNMP、JSP、PyWeb都是你能随口说出来的词，如果用某种架构方式来描述，那就可以称做单体模式（Monolithic，Martin Flower大神所提出的，后面还会介绍），而这些技术都是单体模式的成熟解决方案，它们可以使你工作在“应用层”的最顶端，各种中间件、框架能让你省心地干好业务，开发人员可以通过“模块化”的手段来管理业务系统的复杂度，使他们之间解耦、复用。简单来说，这个单体就是如下这种层次划分。看起来很简单，对吧。诚然，业务系统在这里面还需要做很多，比如缓存、SQL优化、数据分区、系统安全工作，当然还有对于代码的维护和重构。这种工作方式可以很好的工作几年、甚至十年，但是如果业务发展非常快，在系统复杂度、业务规模、参与人数、代码腐化程度都不断上升的情况下，你会发现整个项目正陷于泥潭，PM/RD/QA/OP经常抱怨：“改个小功能，怎么要拉这么多模块？”“拉模块也就罢了，改的地方多，编译太慢了。”“慢也就算了，关键不知道怎么改，这代码太丑陋了，算了，为了满足PM的排期需要，凑合来吧。”“凑合来了，QA发现bug，返工再返工，延期再延期。”“上线了，oh my god，报case了，性能有问题，原来是依赖的模块访问数据库用了for循环select。”透过现象看本质，我总结就这三点问题：1、业务逻辑复杂耦合，开发维护成本高系统复杂度、规模、参与人数都和腐化程度成正比，单纯的靠模块化，后期来看会存在个别模块成为”大怪物“，臃肿不堪，粒度过粗，难以复用。2、交付效率和质量低在敏捷和持续集成方法论、实践大行其道的现今，迭代的按期交付率、单测覆盖率都不尽如人意，线上问题频发。3、非功能需求不达标非功能需求指标特指性能、可用性、可扩展性等方面，代码的腐化和缺少维护、重构，以及没有代码洁癖的人污染下，必然导致性能逐渐下降，甚至出现不同资源竞争的短板效应，造成整个系统crash，同时一个大怪物的伸缩性较差，不能随意横向扩展某个细分功能点。我想任何人做架构都需要秉承“业务需求决定技术演化路线”的思路，那么这些暴露出来的现状和问题都驱动系统去转型，在系统和人之间找到一种最佳的合作模式，匹配已有的生产力和生成关系。正如软件开发学泰斗Kent Beck所说的：“Design is there to enable you to keep changing the software easily in the long term” ，即“变化发生时设计被破坏的程度”。放眼业界，面对复杂的、大规模的、多人协作完成的业务系统，如何管理好这个复杂度，有很多方法，模块化、OSGI、传统服务化SOA等等，当今最佳实践的趋势还是服务化，而微服务是最近火热起来的概念，有些人肯定觉得这不就是炒作嘛，但是不管黑猫白猫能抓耗子就是好猫，所以解决问题是重点，不要刻意去批评一些名字，那么本文要重点介绍的就是——如何做微服务化转型和改造。在接下来讲之前，要重点声明，本文并不是推崇服务化，不鼓励单体模式，相反而是相当肯定和支持单体模式，它模块依赖简单、一个发布包、部署于一个容器都使得构建应用非常的简单，在体量还不大的情况下，首先应该解决的是搭建好一套绝对稳定的基于模块化的平台，待体量逐渐长大，再去根据实际需要进行拆分，团队也随之变化（facebook的单体持续了非常长的时间，一是人员素质高，二就是基础平台建设的非常好）。再下个阶段体量大到饱受单体模式之苦，也应该先建设平台化服务，建设好之后，先按照大的粒度进行拆分，逐步再微服务化，否则，直接上服务化、甚至下面要说的微服务都是非常危险的，鲜有成功案例。2微服务改造做改造一般要经历三个步骤：第一、技术选型决策第二、架构设计规划第三、落地实施应用。下面依次展开三个部分，重点介绍前两个步骤，有了这两个，落地应用也就顺水推舟的好做了。一、技术选型决策1.选择微服务化方式选择服务化，众所周知就是SOA嘛，这是一种架构风格，重点在原则、理念、方法论等高思维层次上，对于工具、框架、解决方案没有做强制限制，ESB、websercie（基于WSDL和SOAP/BPEL）这两种是企业中流行的，也是过去一直引领SOA的技术领头羊，但是随着互联网应用的发展，在敏捷快速迭代、高可用、高性能、高并发等方面要求越来越高，传统的SOA并不适合这种场景。那么，现在的互联网流行的实现方式是什么呢？一种最佳的实践方式就是微服务化（Micro Service）。微服务就是一种SOA的实现方式而已，更加侧重于在服务的细分演化，是指引服务的具体落地方案层面的一种实践方式。过去很多互联网公司在实践，你可以把淘宝的dubbo、HSF，navi-rpc服务化框架看做比传统SOA更适用、更贴近微服务化实现的服务化框架，依赖这些框架可以方便的做服务化。这个趋势被Martin Flower大神所发现，并且提出了，你们这些不都是在做“微服务”嘛。Martin对微服务这个术语（terminology）的解释是：In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built aroundbusiness capabilities and independently deployable by fully automateddeployment machinery. There is a bare minimum of centralized managementof these services, which may be written in different programminglanguages and use different data storage technologies.简而言之，微服务化就是以一系列小的服务来开发支撑一个应用的方法论，服务独立在自己的进程中，通过轻量级通信机制交互（通常是走HTTP协议）。这些服务是围绕着业务上的组织结构来构建的，全自动的、独立部署。几乎看不到中心化的服务管理基础设施，可以使用不同的编程语言和数据存储技术来实现不同的服务。在简单的一种理解来自于一本书《Building Microservices》（Sam Newman, O’Reilly Media），Microservices are small,autonomous services that work together. 微服务化就是一堆小而自治的服务，让他们一起工作起来。相比于传统的SOA，Martin的总结特点可以参考他的博客还有视频，一共是9个特点，这里不想赘述，而是说说我个人的理解，微服务化的特点在于：1、模块即服务微服务中的组件在逻辑或者物理层次更趋于细分，这个细分不是极致的，而是一种粒度适中的选择，通常这些组件在前期可以是一些模块，但是当需要时，例如业务上需要拆分独立，或者非功能需求上需要扩容等，都可以灵活的拆解出来。这个特点非常重要，因为业务系统中模块化实践，随着软件规模的变大，很容易绕过障碍而使得不同模块耦合、依赖关系复杂，这种纪律性很难保证，从而削弱模块化的结构、降低了团队的生产力（敏捷开发和持续交付越来越难做，部署起来太庞大了大家的开发士气不高，而且痛苦），很快的这个模块就会变成一个大杂烩，而服务可以做到天然的壁垒，仅仅通过交换契约（通常是API或者proto）来做交互，这是一个演化的过程，不仅有利于分而治之，到达复用的目的，同时老系统也可以灰度的改造剥离。2、独立自治这意味着服务是独立开发，独立测试，独立发布，独立部署，独立运维的，某个细分团队负责整个生命周期管理，这就是“康威定律”的通俗解释，官方解释是“一个组织的设计成果，其结构往往对应于这个组织中的沟通结构”，服务的规划不就是多人、跨团队协作的沟通模式嘛。好处在于摒弃原来的火车模型（所有模块一起发布部署），拥抱独立快跑，这也更好的支持了敏捷和持续集成的方法实践。同时去除了牵一发而动全身的问题，单一职责的来进行修改需求或者重构一个点，开发和构建方便，不影响整个产品的功能，一个bug不会crash掉整个产品，针对不同的类型，区分计算密集型还是I/O密集型，区分业务上更好使用关系型还是NoSQL，区分2/8原则、即80%经常修改的服务独立出来自成一家，区分短板功能、针对瓶颈可以做水平扩展、避免资源竞争，甚至可以区分技术栈、突破语言限制。最后，这也是和第一点遥相呼应的，独立的服务可以实现非常大程度上的复用，服务之间依赖轻量级的接口，而不是模块。3、去中心化的数据管理在单体模式中，一个应用面对一套数据库，数据库可以按照物理拆分，进行shard分区，或者按照逻辑库隔离，不同的业务路由到不同的库，同时做一主多从等结构上的设计，这些原则在微服务中仍然适用，只不过微服务在服务拆分的同时，也需要将数据库分离，独立的服务维护独立的数据库，这对数据库也是减负，同时技术选型、SLA保证都会区分开来，把精力留给那些重要的业务数据库，进行分级的对待，而不能像以前一样一视同仁，一个不重要的逻辑库的badSQL慢查询，阻塞了其他正常的查询，这是完全可以避免的。4、轻量级的通信协议传统的SOA使用ESB或者Webservice这种重量级的解决方案，微服务推荐使用一些更轻的解决方案，要通用性，可以用Restful架构，走HTTP通道，支持Json序列化协议；要高性能，可以考虑一些高性能的I/O模型，例如epoll、Actor等，可以直接走tcp通道，使用protobuf序列化协议，同时保持长连接（这里有一个例子Navi-pbrpc就是一个这样的具体落地框架）；要异步，用可靠持久的RabbitMQ或者高性能的ZeroMQ来做P2P、Pub/Sub、广播broadcast消息通信。而这种轻量级还需要体现在代码调用中，模块化直接通过函数、方法调用即可，服务化后能不能在API层面做到无侵入，无缝的切换、简单配置，这些都是服务化框架要支持的。5、为失败设计服务化调用从进程内in-process的调用，转变为跨进程的分布式调用，这种由分布式特性引起的天然不可靠性，需要变为相对可控。也就是服务间的通信要假设不会成功，为失败处理。异常的传递，能否透过RPC，在调用方本地还原，就像函数、方法调用一样？一个点、或者服务的处理错误率到了一个阈值，为了不影响整个产品，要做错误隔离，可以考虑熔断（circut break）、舱壁隔离模式、限流、回退等手段，最后还有一个幂等性问题，重试的调用会不会对业务造成影响，这个要具体问题具体分析了。6、基础交付设施自动化这个特点是整个微服务中的最大亮点，包括持续集成CI、持续交付CD和PaaS平台的结合。微服务在细分的背景下，在project结构，物理结构上都提高了一个复杂度，如果还要做到提高软件交付链路的整体效率，就需要在基础交付上做一个大的转变，因此DevOps文化，让每个人都参与交付，在规范的流程和标准的交付（例如，标准的容器）下，同时在PaaS服务提供商的帮助下，完成一个服务的自动部署发布。任何事情都是两面的，有好的优点，当然会存在弊端，微服务的缺点我的理解如下：1、分布式调用造成的性能、延迟问题。（可以采取的措施包括粒度适中、批量、高性能RPC、异步通信等）2、可靠性不好保证。（刚才提到的为失败设计可以解决）3、数据一致性难以保证。（看各自的业务，确保最终一致性即可，实际上大多数互联网产品很少不用事务；但是我目前所工作的商业产品领域，是需要事务的，除了不推荐的两段式提交，还可以引入仲裁者、补偿措施来解决分布式事务问题，问题可以单独开一篇文章介绍了，这里就不展开了）4、整体复杂度提升。服务多、依赖多、调用多、契约如何管理、监控如何做，调用链上怎么确定哪个点有问题，服务的SLA保障、性能、错误率、告警、这么多服务如何集成测试、交付容器如何上线等等问题。（通过服务治理可以有效降低微服务化复杂造成的低效，转为推动工程生产力的高效进化，同时基础交付设施的自动化可以加速研发效率，选择了微服务就等于选择了成本优先战略，投入的成本都是为了未来业务的更好发展，避免J-curve曲线式的研发模式，只有在体量大，基础设施包括服务化框架、治理能力完善的基础上，加上流程、规范以及工具和技能的辅助下，才可以真正发挥服务化的威力，否则只有自讨苦吃）2.微服务化框架和治理模型架构方式、原则达成了共识，你再往下看。虚的说完了来点干货，来介绍下我所在team实践的微服务化，最核心的就是微服务化框架，业界流行的阿里的框架dubbo以及淘宝内部的HSF，Navi-rpc都可以看做微服务化框架的雏形，加上服务治理中心的管理、基础交付设施的保障就可以构成完整的一套微服务框架。我们的框架（暂时仅内部使用）整体架构如下图，他由服务发布者、调用者和治理中心三者组成，属于标准的协调者模式。生产者中服务逻辑在Spring或者Guice等IoC框架的bean中，由IoC容器托管，为了符合模块即服务的思想，在框架层级实现了一套可插拔组件的引擎，去实现组件的扫描，需要暴露服务的发布出来，依赖别的服务的，通过字节码技术生成Rpc调用代理Stub，形成了一个基于组件的容器，通过JSR315这个规范的SPI实现对接到J2EE容器，下面的消费者结构相同。在服务启动后，首先会第一步注册自己到服务治理中心，上传自己的契约、版本上去，治理中心如果通过检查就发布出去，之后和治理中心通过长连接协议（我们采用websocket，因为现成、简单）做一个订阅发布的通道，可以供收集状态，推送服务Endpint的变更；服务消费者可以去治理中心或者Maven仓库获取契约、SDK，治理中心推送Endpoint下来，供路由进行Rpc调用，通过消费者也通过长连接协议来进行状态和统计信息的上报，供治理中心进行分析决策和反馈。服务治理中心为了保证高可用性，通常使用Zookeeper这个流行的开源的基于Paxos的方案，当然最近渐渐流行起来的kebernetes的etcd是基于Raft的集群共享数据、也可以做服务的发现的解决方案。随着这种分布式调用越来越频繁，就需要服务治理能力越来越强，否则就是一张混乱的、无序的Rpc调用的网，无法管理复杂度。这里建立了服务治理的模型，在下图中的服务治理中心来实现，模型从这样几个角度来考虑如何治理服务，包括通信、契约、版本、监控、安全、交付等角度，依托服务治理中心，有了这套基础设施保驾护航，服务化就可以真正做到提高研发效率、提供优雅的开发体验。在基础交付设施自动化上，如下图所示，体现在自动化、容器化交付这个流程中，在平台化的背景下把团队思维转换为DevOps式的，依托Docker和k8s完成了PaaS平台的对接，同时和QA一起协作完成持续交付流程的建立。二、架构设计规划这里所指的架构，特指组织、服务的架构设计，非部署和代码架构。下面我要介绍的，都是扣题，是已有系统的服务化改造，是一个已经存在的、复杂的、体量大的业务系统。做架构设计规划，主要分为步骤：整体架构设计业务领域抽象、建模服务规划与层次划分服务内流程、数据、契约（接口）定义和技术选型。这里主要介绍前三个步骤，第四个偏向于个例，同时需要强结合业务需求、特点分析解决，这里不做详细展开。1.整体架构设计还记得文章开说所说的单体模型吗？在一个复杂的、规模大的业务系统中，使用微服务化方式实现，就需要从上到下的来做整体架构，下面这张图是我所在的商业产品的业务端到检索端的架构图。共分为5个层次。第一层，模块化组装，是各个投放产品的门面，各个投放产品可以通过搭积木式的方式，组装下层服务，就可以完成一个面向用户的功能，最常见的SpringMVC技术、Java设计模式中的facade模式就属于应用到这一层的一些点。第二层，计算服务层，服务化也就是在这个层次上展开的，每一个小圆圈都是一个微服务，这是整个服务化的核心，各个服务圈出来的都是一个个服务簇，比如投放管理一个簇，报告报表一个簇。第三层，数据存储层，会针对各个业务拆分，按照物理库或者逻辑库进行隔离。第四层，广告传输层，将多shard的MySQL写入的广告增量实时传输到检索端，形成一条增量流（incremental data stream），我们通过模拟为MySQL的一个从库来捕获解析binlog实现，将binlog增量映射为语言级别的抽象类型，供下游使用，下面一层就是一个数据接收方，其他的还包括一些MQ订阅方（如导入kafka、RMQ、ZeorMQ等），HDFS存储等，这样就形成了业务系统的数据快速、高效、实时传输的目的。第五层，检索端。是广告投放系统的核心，根据媒体环境、用户特征匹配最佳的广告，进行创意的投放，你所看到了图片、H5、flash广告都是这套系统响应的，可以做到千人前面，最佳化广告主ROI与用户体验的折衷。2.业务领域抽象建模技术是为业务服务的，没有了业务，纯粹的讲技术都是纸上谈兵，解决问题是所有技术的出发点，微服务化也不例外。服务于业务，就需要对业务有深刻的理解，技术才能形成良好的输出。有了前一步的整体架构规划，下一步就是计算服务层中的微服务如何规划的问题，这部分最为复杂，需要深入到产品业务中。拍脑袋规划当然可以，这叫做经验直觉主义，我认为经验主义缺少规范化的表达和标准化的设计，面对未来的修改需求，其架构的生命力不会很强。所以应该站在更高的视角上尝试解决，首先就是要规范化需求表达，下图就是一个投放实施的表达，使用巴克斯范式（BNF范式）表达，将投放实施分为受众、媒体、场景等定向的选择，每种定向又分为多个约束条件，逐层深入，这个规范是所有已有产品的萃取，在新产品的打造中需要遵守的，一般会和产品经理一起打造。然后各个投放产品进行的功能矩阵划分的标准化设计，以这些为基础，就可以有理有据的进行服务规划，抽象分解出来的服务域高内聚，职责非常清晰，服务内的实体也是建模的，如下图所示，每个包都是一个微服务。3.服务规划与层次划分基于对业务的抽象分解，在计算服务层内部，就可以进行更加细分的层次规划，先是垂直拆分为展现层、计算层、数据资源3大纵层，核心的计算层又细分为3个层次，包括业务流程处理层，通过组装下层服务完成功能；业务逻辑组件是自包含，跨产品线、高度复用的组件；下面公共服务组件是一些通用服务。然后水平划分为多个服务簇。如下图所示。按照之前的服务规划，将各个微服务安置其中，最上层的web-ui和api服务负责和前端js以及客户端（安卓或者iOS）API打交道，中间例如推广管理作为一个业务流程处理组件的workflow，可以调用下面的微服务进行组织，完成一个投放流程的业务场景。所有这些服务都是通过分布式服务化框架来进行通信、治理的。三、落地实施应用下面是一个已有产品改造的案例，比如一个报表服务簇，过去是一个大单体，现在按照服务化的架构，进行拆分，最为核心的就是中间这个sync-report服务，它从olap engine中查询数据，然后通过merge字面数据，提供排序，过滤，分页功能。围绕sync-report抽取了多个不同维度的缓存，保证了核心报表服务的高性能，同时上层，不管是web-ui还是api，都复用sync-report，这样上层就会很薄，不用再管那些复杂的查询逻辑，sync-report作为标准、规范的技术解决方案，做到了统一复用与专职专用，加速了研发效率和交付。3小结本文所提倡的微服务，是结合作者所在team自身业务特点来说的，适合自身的场景，是建立在团队人员素质到了，有成熟的基础设施和框架、中间件辅助，流程也规范，包括CI、敏捷等，团队都做好了准确去做这个转变，有足够的能力来实施，微服务化也就是水到渠成的事了。相反，小团队在前期或者野蛮生长时期，不宜选择微服务，不但影响效率还带来额外的复杂度。成长型或者大公司，有成熟的流程、规范、基础设施、平台等，要想在整条交付链路上加速，就需要投入更多的资源保障微服务化，一切自动化了，能治理了，回头看来这一切就都是值得的，远期收益非常可观。最后要说的是，架构只是标准、骨骼，对微服务的讨论不应该让我们忘记了更重要的问题，驱动软件项目成功和失败的重要因素。软因素如团队中人的素质，以及他们如何彼此合作、沟通，这都会对是否使用微服务有很大的影响。在纯技术层面上来讲，应该把重点放在干净的代码、完善到位的测试，并持续关注架构的演化进步，这才是一个软件工程师的根本职责。
关注微信公众号：东碣科技咨询IT技术，了解行业解决方案
(长按图片识别二维码)}