kimmking：解析软件架构发展历程-交流实录

2018年2月28日，周三晚上8点30分，前阿里架构师、某商业银行北京研发中心负责人、某电商公司高级技术总监的 kimmking 带来了主题为《软件架构发展历程分享》的交流。以下是主持人天怡整理的问答实录，记录了作者和读者间问答的精彩时刻。

内容提要：

• 微服务架构中有哪些 framework 的 jar，分别是怎么划分的？
• 微服务架构实际体现的是组织的结构，对于微服务架构自身的演进，现在是什么规律？
• 请问初次接触一个中等到复杂程度的项目时，如何快速熟悉其架构？
• 技术选型时，那么多的框架，怎么知道哪个适合？
• 架构设计需要一开始就大体结构设计并且固定好吗？实际在开发过程中可能会增加新需求，这个新需求可能会需要架构的修改，如果在原来的架构基础上迭代开发，开发的时候会有非常勉强的感觉。遇到这种情况的时候怎么处理才更好？
• 初期评估项目，设计架构的人留了坑，作为后续负责项目的人，想优化架构，应该怎么办？
• 初次接触一个中等到复杂程度的项目时，如何快速熟悉其架构？
• 遇到问题扩容服务器配置或数量，我想问下这样简单的架构好，还是将业务进行架构上分拆分，应该如何衡量综合考虑呢？
  

问：微服务架构中有哪些 framework 的 jar，分别是怎么划分的？

答：此问题其实是开发和部署的问题。用 jar 的角度去看，不如从子项目和部署单元的角度来看。一般来说，我们把系统拆分成多个不同的、独立的微服务，这个层次上，自动就划分成了多个单元。然后每个微服务作为一个子项目，开发期的项目结构是可以再次划分的。如果子项目也相对复杂，可以拆分成更多个 sub project。但是每个子项目作为一个服务，是需要部署到一个容器的。

---

问：微服务架构实际体现的是组织的结构，对于微服务架构自身的演进，现在是什么规律呢？

答：这其实说得是康威定律（Conway's Law）。原来的意思是团队的组织方式必然影响了系统的设计方式。这其实是一个很显然的问题。我们也可以进一步延伸一下：每一个系统都是为其所有的用户服务的，这些用户的角色决定了他们在系统里能操作的功能，所有的角色和功能串起来就是所有的业务流程，这些组织形式是系统设计最直接的体现。在研发团队这里也是一样，一个分散的团队可能采用一种分散的架构设计，团队的沟通方式势必对系统组件的拆分和组合产生影响。

---

问：请问初次接触一个中等到复杂程度的项目时，如何快速熟悉其架构？

答：项目的范畴比代码大。我们先说熟悉代码。架构源于业务，了解业务是基础。然后接触到一个新项目的代码，如果有相关设计文档，最好先看看文档，对于有疑问的地方，找当事人问是最高效的办法。熟悉具体的代码的话，一个是看整体代码结构，SSH、SSM 的 MVC 结构也好，DDD+ 微服务方式的代码结构也好，了解了结构看具体代码就可以知道这一块代码在所有代码里处于什么位置，起什么作用。再详细看使用的各个技术细节。还有一个就是，最好要把系统跑起来，主要业务场景 debug 单步跟踪调试一遍，这样就知道你看的、想的东西是不是跟实际的一致。如果是项目的话，还需要了解各种非功能需求和实际的部署架构等。

最后一点是平时多看优秀的项目代码，特别是知名开源项目，看得多的、想的多了，经验自然多了，一般的项目就不在话下了。

---

问：技术选型时，那么多的框架，怎么知道哪个适合？

答：框架的技术选型问题是一个非常常见的问题。比如 Mybatis 和 Hibernate，Struts 和 SpringMVC，Tapestry 等。一个成熟的框架，都是经过非常多的项目验证过的，使用熟练了感觉区别不大。没有使用熟练的情况下，选择最成熟的、案例最广的、文档最多的、上手最快的。非常熟练了，而且团队的技术能力不错的情况下，选择自己比较能更好控制的，有能力完全 cover 的，跟自己的整个研发技能积累沉淀的基础设施融合的最好的。比如说自己基于 Mybatis 做了一些封装，实现了一些代码生成工具等。框架都是别人的，用熟了也还是别人的，只有继续发展形成自己的武器库才是自己的。

---

问：架构设计需要一开始就大体结构设计并且固定好吗？实际在开发过程中可能会增加新需求，这个新需求可能会需要架构的修改，如果在原来的架构基础上迭代开发，开发的时候会有非常勉强的感觉。遇到这种情况的时候怎么处理才更好？

答：软件架构设计作为一个领域专门发展开来，就是为了总结经验便于以后更加灵活，更好扩展，更好维护。无论是 MVC 的划分，还是组件化，服务化，到现在的微服务架构。因为我们的系统需求和流程本身，我们的业务外部市场竞争环境，我们客户的实际需要，都是在不断发展变化的，系统必须跟着一直发展变化。我在文章里提到了，设计必须有一定的前瞻性，架构是需要不断发展变化的。类似我们做业务规划或技术规划，我们需要适当考虑以后几个月、半年、一年甚至再长一点的长远考虑。不仅是需求，还包括系统的非功能性需求，比如性能，扩展性。这需要我们对原本的业务有足够的拆解和抽象能力，形成某种业务和系统的架构模式。如果具体到代码层面，那就是很多的优秀代码设计的经验，我们一般称为设计模式，大家需要灵活应用各种设计模式（比如 GoF 的23个设计模式等）。

---

问：初期评估项目，设计架构的人留了坑，作为后续负责项目的人，想优化架构，应该怎么办？

答：这实际上是两个问题，一个是怎么填坑，一个是怎么从技术到架构师。

填坑的事儿，在哪儿都有，不仅仅是软件开发这件事儿上。处理办法一般就是搞清楚坑有多少，问题有多严重，坑在哪儿，处理办法都有哪几种，解决的代价分别有多大。当然这个评估本身需要对项目非常了解，也需要花费很多时间精力。作为一个接手项目的负责人，这个时间是你必须去争取的，不然在你手上雷随时会爆炸。

怎么成为架构师，这是职业规划问题。如果你有兴趣，有志向成为架构师，那么请认真对待你经手的每一个项目，努力从每一个技术问题考虑最优解并去尝试改进，努力从自己负责的模块之上更大视角的去考虑和分析问题，努力学习各种层出不穷的新技术和新思想，努力去阅读和理解优秀项目的架构设计和代码（特别是知名开源项目代码）。还有就是积累，积累自己的知识面，在某一方面的具体领域成为专家。我的文章中也提到了，技术领域是符合一万小时定律的。不断努力的读、写，思考，突破自己，你一定会是一个优秀的架构师。

---

问：初次接触一个中等到复杂程度的项目时，如何快速熟悉其架构？

答：项目的范畴比代码大。我们先说熟悉代码吧。架构源于业务，了解业务是基础。然后接触到一个新项目的代码，如果有相关设计文档，最好先看看文档，对于有疑问的地方，找当事人问是最高效的办法。熟悉具体的代码的话，一个是看整体代码结构，SSH、SSM的MVC结构也好，DDD+微服务方式的代码结构也好，了解了结构看具体代码就可以知道这一块代码在所有代码里处于什么位置，起什么作用。再详细看使用的各个技术细节。还有一个重要的就是，最好要把系统跑起来，主要业务场景debug单步跟踪调试一遍，这样就知道你看的、想的东西是不是跟实际的一致。如果是项目的话，还需要了解各种非功能需求和实际的部署架构等。

最后一点是，平时多看优秀的项目代码，特别是知名开源项目，看得多的、想的多了，经验自然多了，一般的项目就不在话下了。

---

问：遇到问题就会扩容服务器配置或数量，我想问下这样简单的架构好，还是将业务进行架构上分拆分，应该如何衡量综合考虑呢？

答：很多个一模一样的服务器，然后加机器做整个集群的扩容，我们一般叫垂直架构，如果传统的业务领域和规模较大的公司，费用也没有问题，这种是很常见的，比如银行电信。
现在流行开的分布式服务化架构（DSA），微服务架构（MSA），其实是比较倾向于更细粒度的拆分，这样后面可以用对每一块的精细化的处理，来更加灵活的应对系统需求的变化。但是为什么传统业务比如银行的非互联网类或创新类业务，可以用十多年前的技术架构呢？原因在于不差钱、变化少。
具体采用什么架构，需要综合考虑：成本，技术，人员，团队能力成熟度，目前的现状，等等很多因素。如果你的系统需要长期发展和维护，你这里的人力物力也都跟得上，可以逐步尝试一下新的技术架构，这也是对未来的一种投资。

圈子的提问：

1、基于微服务架构下，如何快速高效的进行测试覆盖？

微服务架构由于拆分粒度较细，测试是个大问题。在保持每块职责单一的同时，关键是保证接口稳定，做好自动化测试（特别是UT和接口的自动化）和持续集成，尽量少全流程的人工回归测试。

2、去耦合是一个古老的话题，为何近几年才兴起微服务的概念？

微服务因为拆的很细，依赖于很强的服务治理，自动化运维和测试技术，已经近年发展的docker轻量级容器。

3、考虑到很多公司的现实情况，存在有很多的单体遗留系统的情况下，如何规划和实现微服务的系统架构呢？能否分享一些相关的改造或演进的案例？谢谢！

这是一个非常好的问题。几句话说不清楚，总的来说需要整体规划，循序渐进，拆解合理，服务先行，优化团队，技术提升。特别是做微服务化之前最好明确目标定位。

这个过程很特殊，很有挑战，也有几个不同路径可以选择，遗留系统总归会因为各种问题导致坑很多。但是这个过程下来对于团队的整体能力提升是有很大的推动效果的。、、后面我会单独作为一个讲座来详细阐述。

4、请问开发构架，框架，软件工程模型之间有什么关系，如何结合？

开发架构一方面是为了实现我们的系统架构，另一方面是为了更好的组织研发。框架的选择其实是技术架构的一部分，反过来又会影响我们的研发组织形式。

典型的使用SSH/SSM的话，就选了一种对项目开发和运行视图的一个基础划分结构，怎么分层便于装配，怎么处理不同层次的关系、怎么处理通用性的一些非功能性需求等等，配合业务模块和功能的划分，把项目结构清晰的确定下来便于任务估计、工作分配和大规模分工协作。

5、利用Docker如何轻松实现云原生应用实现高可用架构设计 ，微服务架构的风险该如何把控？

docker实现了轻量级的虚拟化，使得服务之间可以更好的隔离，并且带来更好的性能和自动化部署，但是它并不能直接实现高可用架构设计。这是两个问题。

微服务架构的是风险主要是：

（1）对业务按粒度和边界拆解的问题，这决定了我们的服务是不是合理，开发和维护是不是方便。核心思路是深入了解业务。

（2）多个服务间的业务数据一致性的问题，事务是个需要重点考虑的问题，主要是考虑强一致性还是可以使用最终一致的弱一致性。对于一般的业务，可能使用补偿冲正类的做法，在业务允许的一定时间内数据达到一致状态即可，比如30s，或者10分钟。

（3）跨系统的协作问题、测试的问题，这对于技术能力和研发成熟度较低的团队，会带来很大麻烦。核心思路定义好业务边界、系统间接口与数据标准，提升自动化测试水平。

（4）部署单元太多导致维护成本上升的问题，要管理的点多了，问题自然复杂了，核心思路是自动化部署与运维。