一、前言
泱泱蓝图，出口成章，落地就慌，面对复杂的微服务架构却一筹莫展。
这是很多缺乏相关架构实践经验的IT团队面对复杂微服务架构如何落地的现状，微服务最后变成了“伪”服务。
软件工程系圣经《人月神话》告诉我们，不可能一下子设计出很完善的产品，但是我们总有时间做出一个可用的产品，架构设计亦是如此，行动起来，否则我们将成为听过很多大道理，依然过不好这一生当中的一份子。
但如果行动过程能有一个经验指导，帮助我们减少因为考虑不周而产生大量技术债务则是极好? 今天我们想尝试来做这件事，把经验分享出来, 优顶特技术团队通过对产业互联网平台优顶特网开发过程中遇到的技术问题和架构问题总结，本着向前思考，向后推导的指导思想, 在此打造一个微服务架构落地系列专栏，给您呈现一个可照搬的微服务构架，从方法论到落地实战路径&工具一应俱全，帮助您打通架构落地的最后一公里, 同时, 在不久的将来待时机成熟，优顶特技术团队将在开源平台公开相关源代码。
二、分析
手中有粮，心中不慌, 慌的本质原因是团队缺少一套能切实落地的理论体系指导及技术体系指导，开源生态或社区仅提供了原子组件或抽象架构，还达不到实际指导业务开发团队进行开发落地的级别, 优合集团优顶特技术团队通过在产业互联网平台优顶特网建设过程中的摸爬滚打，实践总结优化出了一套微服务架构落地方法论和技术工具，希望能帮助到缺乏相关经验的团队在做设计时少走一些弯路，少踩一些坑，少趟一些雷。
我们先通过一张优顶特网简单业务架构图做一下认知对齐。
特点和各大B2C互联网平台类似，功能模块大而全，承接优合集团全产业链业务，面对大而全且复杂的场景, 根据微服务分而治之的思想，当然是"拆"字诀啦，关键是如何分拆?
拆得好是这样
拆不好则是这样
三、方法
谋定而动，如何谋?
我们先从方法论出发，把准备工作做好，做到心中有数. 分析问题->定位问题->解决问题->提炼方法论->实施模型, 先从两张图来直观分析对比一下单体架构和微服务架构的区别。
单体架构
微服务架构
由上图可以分析出相对大单体架构微服务架构有包括但不限于如下优缺点：
优点：
系统边界粒度更细；
各服务高度自治；
开发协作效率高；
开发代码冲突少等。
缺点：
架构复杂；
服务数量膨胀；
调用链复杂；
运维部署复杂度急剧上升等。
面对这些缺点我们技术层面如何尽量提前规避或制定好规则？因为这些缺点如果不提前做好预防机制，随着服务的急剧膨胀，整个架构将会变得混乱无序，技术债务大量堆积，最后变成一场技术灾难。
根据我们团队实践总结, 建议团队先从方法论体系上做好以下全局规划，正所谓不谋全局者，不足谋一域，高度精简总结下来就是标准化、自动化、虚拟化三化体系。
标准化---解决架构复杂等问题
编码规范标准化；
工程骨架标准化；
组件标准化；
异常处理标准化。
自动化---解决运维复杂等问题
工程搭建自动化；
通用逻辑代码编写自动化；
数据库升级管理自动化；
运维自动化。
虚拟化---解决运维复杂、调用链复杂等问题
服务容器化；
资源虚拟化；
以上体系中，有些是开发要干的活，有些是运维要干的活, 所以说微服务架构最好要有与之相匹配的组织架构, 至于每个点怎么干, 请关注后续。
下面先预告一下我们团队做的一些标准化工作成果。
微服务架构参考标准原型
微服务代码工程参考标准骨架
四、总结
本文先对微服务架构落地前, 技术和运维上需要做的体系化准备工作做了整体总结归纳，让大家有个整体的认知, 不过对于coder来讲这肯定还远远不够，毕竟始终是 Talk is cheap,Show me the code, 后续文章我们将依次推出围绕以上三化体系如何具体推进落地，具体要做什么, 做更细粒度的包括但不限代码级别的拆开讲解，尽请关注此系列的后续。
