读《美丽架构》学习初探思考1

谁是架构师？

首先我本人肯定不是，要不然才不来这探。什么样的是架构师： 部门里面的架构师是合格的架构师吗？ 应该是吧。不过说实话看着部门的产品，架构真的不行。
架构师要给产品，给业务画草图。包括那些呢？产品功能和具体的需求，会有规划经理和PO给出来，大公司的架构师不用关注什么功能，需求。具体的时间成本和项目规划，通常由项目经理来搞，这些也没有什么技术含量，这里略掉。架构师应该干那些事个人见解如下：

1 首屈一指，我觉得应该是：系统的性能， 扩展性。

让你用apache来搞个认证系统， 架构出来的并发只有几千，并且不能随着设备内存和CPU提升而提升，那是垃圾。整出来的新建只有几十个，稍微大点的客户或者互联网级别的都不敢用这系统，卡的不要不要的。

好的架构，它就像没有瓶颈一般， 你给它多少core，多少内存，它给你成倍的往上翻，说实话我本人对于多线程编程非常钟爱，经过分发的或者分离的业务模型，无需线程间共享数据或者有着低频的共享，通过延迟删除等技术，躲避需要实时加锁对数据区进行保护，狠怕数据已经被delete，还有人用。

好的扩展性，说实话简直是程序员的情人。 扩展性不好，会导致程序修改起来像是噩梦， 最讨厌的是：你的程序不满足客户需求，要定制吧。定制完以后，和系统绑定了吧。 过了一两年你的版本升级了， 做过定制的客户，想要升级的时候， 又要定制， 如是反复。这就是没有好的扩展性，导致没法通过扩展增量插件实现业务或者替换业务，虽然我不知道怎么做可以完美，但是却深深知道这里的坑有多深。

2 业务模型的考虑

现在的业务，如果不能支持分布式、或者集群，简直像是一件十分Low逼的事情。不是装逼，而是现在的业务规模成倍的翻，这些真的是刚需。笔者所在的公司，平时就是集群折磨的很惨， 各种会话的同步，会话因为用户的L5变化导致sess漂移等。如果集群间同步的有问题，那么用户飘逸的额时候就惨了。

3 技术栈

架构师因为第一点第二点的考虑， 必然需要慎重选择技术栈。 为啥呢？
c语言的开发效率和难度与高级语言比，肯定差了不少。用C开发的apache服务端与nodejs开发的后端比，性能可能没高多少，但是开发和维护难度，确实翻倍的往上升。技术栈也是我特别感兴趣的，期望有机会可以多了解几种，例如写了python就让我嫌弃c， 但是，服务端开发的话，nodejs的确是个人才。

同时，技术栈真的可以很大的影响项目的进度和工期， 当然也不能盲目，没有大山依靠着，再高级的语言也能把一个软件团队打趴下。

4 好的架构青春永驻

年轻不仅仅是人，软件也当如是。 好的架构能够允许程序被不断拓展新业务，不臃肿。要做到这些，除了大的业务模块的严格隔离， 模块内部的可扩展性也非常重要。我门部门的业务，经常会有多个业务模块之间的配合， 之前的处理因为工期的需要或者架构师不合格， 经常是不同的模块需要通信的时候，直接一个ipc就过去了，对端在收到消息的地方统一处理。说实话，这种烂逼代码搜起来的时候，特别费事。

此处有讨论

我觉得，进程间通信应该有专人管理和路由， 所有进程间通信的接口只应该有一个，通过路由到消息的目的进程号和消息来处理。虽然这样可能会增加进程间通信的次数，增加整个系统的IO负载，但是我觉得这是值得的！当然这个消息路由进程的压力貌似比较大。可以起多个路由进程，客户端进程注册消息的时候，通过负载到不同的转发进程就可以，这是个好主意吗？

此处有讨论！希望大家参与，讨论可以激发更深层次的理解， 或者大家不吝赐教，教会我这个无知的人类

5 可测试性

好的架构应该具有可测试性。 假如我是dp的架构师，我在考虑数据转发的时候，就应该考虑是否能够增加一种测试工具， 允许系统本身就能通过模拟数据库不断地转发，来进行模拟测试。

如果我是一个web后端的架构师，我就应该考虑到一套测试框架，允许模拟用户登陆，注销，访问资源等等行为。 在架构业务的时候，就应该考虑到测试代码怎么加等等…

期望此处有人指教，哪些开源的框架有很好的测试框架？ 非互联网工程师，眼界有限。

6 文档的完备性

说实话，文档非常重要。 因为后期的改进，是基于对之前的业务和架构完全清楚的情况下，否则架构就被改掉了。 最开始的架构师的精神烙印就丢失了。对架构的误解是很可怕的。有可能会导致后面的架构极不稳定。

7 基本的设计原则

信息隐藏，高内聚，低耦合等等原则， 原理虽然简单， 但是实践的好还是很牛逼的。 刚开始实践起来还是很简单的，难的是有足够的框架，保证后面的人还能遵循这些原则。

好了今天就到这， 上面是看了美丽架构的一章内容，然后结合自己的共组的所思所想。如果有兴趣，千万要在下面留言，一起讨论，我虽不是架构，却有一颗架构的心，不是虚荣，而是期望能够创造出更高质量的软件。