架构设计

典型回答 技术选型，没有最好，只有更合适。 当我们要做技术选型的时候，通常需要考虑很多因素，然后再综合对比各个因素，最终选择一个相对比较合适的技术方案。 一般需要考虑以下几个因素： 首先就是看一个工具、或者框架的功能是否能够满足业务、技术需求，这是一个大的前提，如果不能满足需求，有再多的优点都没用。而满足需求又分为多个方面，一个是当前的需求，一个是未来可能会需要的需求，所以这就需要开发者或者架构师仔细去对比各个方案的功能列表，从中选择更加适合自己团队的。 功能符合的话，其次还要看这个技术使用的人多不多，如果用的人多，那么当我们使用过程中，遇到问题的话，就能很快的找到答案。 一般来说，用的人多的技术，bug就少一些，开源社区也更加活跃一些，那么，他的更新迭代速度，以及问题的解决速度也就更快一些。这些对于生产环境中使用某个技术来说还是比较重要的。 提到bug，这就需要考虑一个技术在非功能性需求以外的一些基本要求，比如可扩展性、安全性、性能等，这些可能在短期影响不大，但是随着业务的逐渐增长，这些都可能成为瓶颈。 另外，在成本上也是需要重点考量的，成本包括很多，使用成本、学习成本、迁移成本、维护成本等等，不仅仅眼前要付费的叫成本，人员的上手速度、后期的迭代维护，这些都是成本。有很多东西，用起来免费，但是学习成本很高，后期问题也多，那也并不一定是最佳选择。 还有一点也很重要，那就是引入的这项新技术或者框架，和公司内部现有技术体系的匹配度怎样么？不能说全公司都用kafka，你非要用rocketmq吧？ 所以说，做一个技术选型，需要在：功能性、非功能性需求、是否足够成熟、使用的人多不多、开源社区是否活跃、学习成本，使用成本，维护成本，以及和现有技术的匹配度如何。

典型回答 一百个架构师眼中，有100种微服务拆分的方式，那么我简单总结几个我在做类似的事情的时候会参考的一些原则： 1、职责。我们学面向对象的第一天，就被告知要职责单一，而一个微服务也一样，他应该聚焦干一件事儿，否则他就不够"微"，至少在电商中，我们要把用户和交易拆分开。 2、业务。我们说技术是为了业务服务的，所以微服务的构建需要围绕着业务来做，不同的业务需要独立出来，比如保险业务中，投保和理赔，就是不同的业务，那么就可以把他们拆分开。 3、中台化。当我们在做业务拆分、职责划分后，可能会有一些公共的部分，这部分内容分别在各自微服务实现一份也可以，单独独立出来也是可行的，所以如果考虑中台化的思想，一些公共的部分，是可以独立拆分出来的。 4、系统保障。在做微服务拆分的时候，可能需要根据不同的系统保障级别做拆分，比如秒杀和日常交易，就可以单独拆开，针对秒杀做单独的可用性保障。还有一种就是在线任务和离线任务，也是可以拆分开的，各自做可用性保障。 在线任务：就是你应用中一直都在运行的任务，比如你的订单系统，他的下单、退款正常这些操作都是在线任务。 离线任务：一般是那种异步扫表、或者定时执行的任务，比如订单的到期关闭等。 5、技术栈。要考虑技术栈，不同的技术栈，不要硬往一起融，最后只会让这个系统无法维护。 6、依赖关系。拆分之后，各个微服务之间，不要有循环依赖。依赖应该是单向的，而不是循环的，循环依赖会给服务治理，链路追踪带来很大的挑战，并且存在循环依赖一定是拆分的不够合理 7、康威定律。最后一点，康威定律，应用架构要和组织架构一一对应。组织架构决定了业务架构、应用架构。说白了，就是多个团队一起维护一个微服务，一定会存在沟通、（发布）冲突、谁来干等问题。

典型回答 这个问题是很多读者在一些文章中评论的，因为我多次提到过没有银弹，那么这是个啥意思呢？ 没有银弹，其实来源于一本书，书名叫《没有银弹：软件工程的本质性与附属性工作》翻译自《No Silver Bullet—Essence and Accidents of Software Engineering》 这句话表达的意思就是：由于软件的复杂性本质，没有一个什么技术、手段、方案是可以解决所有问题，而不带来任何负面影响的。 书中的故事： 在民俗传说里，所有能让我们充满梦靥的怪物之中，没有比狼人更可怕的了，因为它们会突然地从一般人变身为恐怖的怪兽，因此人们尝试着查找能够奇迹似地将狼人一枪毙命的银弹。 我们熟悉的软件项目也有类似的特质（以一个不懂技术的管理者角度来看），平常看似单纯而率直，但很可能一转眼就变成一只时程延误、预算超支、产品充满瑕疵的怪兽，所以，我们听到了绝望的呼唤，渴望有一种银弹，能够有效降低软件开发的成本，就跟电脑硬件成本能快速下降一样。 但是，我们预见，从现在开始的十年之内，将不会看到任何银弹，无论是在技术上或管理上，都不会有任何单一的重大突破，能够保证在生产力、可靠度或简洁性上获得改善，甚至，连一个数量级的改善都不会有。 然而，怀疑并非悲观，虽然我们预见不会有任何重大的突破，而且事实上，我相信发生这种重大突破也不符软件的本质，但是，仍然有许多令人振奋的创新正在进行当中，若能按部就班、持之以恒地予以发展、散布，并灵活运用的话，想必应该会得到一个数量级的进展。快捷方式是不会有的，但有志者事竟成。 人类能克服疾病的第一步，就是以细菌说（germ theory）淘汰了恶魔说（demon theory）和体液说（humours theory），正是这一步，带给了人类希望，粉碎了所有奇迹式的冀望，告诉人们进步是要靠按部就班、不辞劳苦而来，得在清洁卫生方面持续不断地投入心血，养成良好习惯，才是正道。如今，我们面对软件工程也是一样。