管他什么利弊权衡，小孩子才做选择题，成年人全部都要

茅草房到现如今的高楼大厦，灯红酒绿，那都市历史迭代的产物。

日行百里到现如今的火箭升空，那都是科技迭代的成果。

迭代及演进，让生活越来越美好。而技术的演进与迭代也让软件开发朝着更加美好及简单的一面在进行着。

近10年，软件行业发生着天翻地覆的改变，这之中也应为诞生了很多牛逼的公司(腾讯，阿里，华为，小米，京东...），说起电商第一想到的就是淘宝、京东，说起及时通讯第一想到的就是腾讯、陌陌，说起通讯及网络第一想到的就是华为，说到打车就想到滴滴，说到点餐就想到美团。618-家电购物节日，11.11-购物狂欢节....。小黄和小蓝选择的确很难。

这些公司的成功及持续成功并非如今日所盛传的一句话，站在风口上“猪都会飞”的。而是都有技术的沉淀以及后续的没一次迭代升级。qq及微信，不知到升级过多少版本，技术不知道重构多少次。淘宝的技术架构，不知道推翻重来过多少次。假设他们在成功的时候，都停止更新就迭代，那么追赶者肯定早就把他们干在沙滩上了。要想在当今网络如此发达的时代，只要有一点点香味，会迎来无数的竞争对手，毕竟赚钱的事情哪个不想。所有越大越牛逼的公司，对技术的要求及迭代速度都比较高。

开发软件，笔者看来，就如修马路。第一：调研当前的车流量（一段时间）。第二：调研近几年的车流量（分析及判断趋势）。第三：根据周围的楼宇，判断未来的增长趋势（满足未来）。而不是一上来，脑袋一拍，10米，5米，3米，最终抓阄来决定。宽了，经费不足，修不出来。窄了，等不了几年，拥堵不堪，导致重修。

一个10人使用的内部管理系统，一来就上微服务，分布式，前后分离，服务动态编排等，自动化部署加运维，链路追踪，分布式日志管理，服务编排等。那不是高射炮打蚊子？选择什么样的技术架构，应该根据软件解决问题的群体及当前所拥有的资源及软件未来1-2年内及用户的增长来判断。而不是为了技术而技术，为了别人眼中的好而追赶，适合自己的才是最好。每一种架构都有他存在的必然性，不然怎么有各自的优缺可言。汝之蜜糖，彼之砒霜！

软件发展的几个阶段

 我接触过的几个阶段（单体，分布式，微服务），当时我还记得后端使用struts2、hibernate,前段使用jsp,前后在一起。前段开发相应的html文件，由后端人员去绑定相应的数据。在后来，springboot出现，vue完美上传，前后分离真正意义上开始实施，后端负责逻辑性相关的编码，提供对应接口文档，前段更加接口文档，来联调接口，此时前后代码做到了分开部署(也可在一起).前后端的分工逐渐清晰，后端程序员，在也不用无缘被丢锅，原来只要有问题基本找后端，而现如今，前后问题一目了然，一个f12即可显现原形。

分布式当时用过doubble,当时基本是后端设计高并发的接口使用doubble来开发（后端，登录，发验证码，秒杀等）。流量较小的还是通过springmvc大单体架构要开发。当时觉得doubble还是挺牛的，只要服务方提供相应的interface,消费方配置相应的配置就能调用服务。而到后面，发现doubble有的功能，springcloud均实现，而springcloud有的doubble需要自己额外实现，故转而研究springcloud.

而本人工作至于演进及使用springcloud开发应用，我觉得几点好处，1.框架搭建好后，只需关心非框架层的代码。2.一处改动，仅仅影响一处 3.自由选择  4.扩展性好

单体架构（Monolithic）

“单体”只是表明系统中主要的过程调用都是进程内调用，不会发生进程间通信，仅此而已。

单体架构就如“一锅顿”

一锅顿美味的菜肴，是把所有的菜及香料放入锅中一起顿。一锅顿便宜懒人及人少的时候方便。当家里来客人的时候，问题就暴露无疑。比如：张三的老婆对羊肉过敏，但是李四的老婆喜欢，这时候如果一锅顿，那么张的老婆放入羊肉后，她到时觉得人间美味，而李的老婆就为过敏难受-“汝之蜜糖，避之砒霜”。故此，“一锅顿”还得分具体情况而选择。

单体系统的真正缺陷不在如何拆分，而在拆分之后的隔离与自治能力上的欠缺。由于所有代码都运行在同一台服务器之内，无需考虑模块与模块之间的调用及网络开销。获得了进程内调用的简单、高效等好处的同时，也意味着如果任何一部分代码出现了缺陷，过度消耗了进程空间内的资源，所造成的影响也是全局性的、难以隔离的。譬如慢sql瓶颈，导致服务宕机、服务被攻击导致所有服务瘫痪，内存泄漏、线程爆炸、阻塞、死循环等问题，都将会影响整个程序，而不仅仅是影响某一个功能、模块本身的正常运作（鱼和熊掌焉能兼得）。如果消耗的是某些更高层次的公共资源，譬如端口号或者数据库连接池泄漏，影响还将会波及整台机器，甚至是集群中其他单体副本的正常工作。

再者，程序代码在一起，所有的框架及业务代码混在一起，对代码的管理及安全考虑也是很大的风险考虑。程序升级、修改缺陷往往需要制定专门的停机更新计划，做灰度发布、A/B 测试也相对更复杂。

再或者，由于代码混在一起，没修复一个bug或者没一次版本升级，测试人员大则需要拉通通测一遍功能，下则测试相关功能，而且不能保障线上还有没有隐藏的问题。

不过，微服务在当前成为当红框架，我认为主要原因：单体系统很难兼容“Phoenix”的特性。这种架构风格潜在的观念是希望系统的每一个部件，每一处代码都尽量可靠，靠不出或少出缺陷来构建可靠系统。然而战术层面再优秀，也很难弥补战略层面的不足，单体靠高质量来保证高可靠性的思路，在小规模软件上还能运作良好，但系统规模越大，交付一个可靠的单体系统就变得越来越具有挑战性。然而随着软件架构演进，构筑可靠系统从“追求尽量不出错”，到正视“出错是必然”的观念转变，才是微服务架构得以挑战并逐步开始取代运作了数十年的单体架构的底气所在。

微服务架构就如“三菜一汤”

“微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。

微服务追求更加自由的架构风格，摒弃了SOA里面的约束与规定，提倡以“实践标准”替代“规范标准”。只是微服务的注册发现、服务追踪、负载均衡、故障隔离，等等。在微服务中，不在会有统一的解决方案，都由架构人员或者开发人员自己选择搭配，必然注册中心使用nacos、eureka、Consul,ZooKeeper等，配置中心：nacos、appllo等。总之，完全是百花齐放，百家争鸣的局面。

微服务带来的是双刃剑，自由的选择需要引入的工具、组件，无需什么都要的自由选择。然而，由于选择性对，对架构能力的要求也大大提高，技术架构的第一职责就是权衡利弊，那么要知道利弊，就不得不具体深入了解没一个组件及优缺点，如果架构者本身的知识面不足以覆盖所需要决策的内容，不清楚其中利弊，恐怕也就无可避免地陷入选择困难症的困境之中。

管他什么利弊权衡！小孩子才做选择题，成年人全部都要！